Chore: Typos fixed in docs folder (radius-project#6543)

# Description

_Please explain the changes you've made._

This PR fix the typo in multiple files.

```pseudo
environmnet > environment
authentification > authentication
unneccesary > unneccessary
orientied > oriented
responsiblity > responsibility
defintions > defination
```

## Type of change
<!--

Please select **one** of the following options that describes your
change and delete the others. Clearly identifying the type of change you
are making will help us review your PR faster, and is used in authoring
release notes.

If you are making a bug fix or functionality change to Radius and do not
have an associated issue link please create one now.

-->

- This pull request is a minor refactor, code cleanup, test improvement,
or other maintenance task and doesn't change the functionality of Radius
(issue link optional).

<!--

Please update the following to link the associated issue. This is
required for some kinds of changes (see above).

-->

## Auto-generated summary

<!--
GitHub Copilot for docs will auto-generate a summary of the PR
-->

<!--
copilot:all
-->
### <samp>🤖 Generated by Copilot at 221f755</samp>

### Summary
:pencil2::books::memo:

<!--
1. :pencil2: This emoji is often used to indicate a minor or cosmetic
change, such as fixing a typo or a formatting issue. It can be used for
any of the changes listed above, as they are all related to improving
the clarity and accuracy of the documentation.
2. :books: This emoji is often used to indicate a change related to
documentation, such as adding, updating, or removing information. It can
also be used for any of the changes listed above, as they are all
related to the documentation of the project.
3. :memo: This emoji is often used to indicate a change related to
writing or communication, such as adding comments, notes, or
explanations. It can also be used for any of the changes listed above,
as they are all related to the written content of the documentation.
-->
This pull request fixes various typos in the documentation of the radius
project. The typos affect the files
`./docs/contributing/contributing-code/contributing-code-reviewing/README.md`,
`./docs/contributing/contributing-code/contributing-code-control-plane/configSettings.md`,
`./docs/contributing/contributing-code/contributing-code-writing/README.md`,
`./docs/contributing/contributing-releases/README.md`, and
`./docs/ucp/code_walkthrough.md`.

> _`radius` docs shine_
> _typos fixed with care and skill_
> _autumn of errors_

### Walkthrough
* Fix typos in various documentation files
([link](https://github.com/radius-project/radius/pull/6543/files?diff=unified&w=0#diff-c5a6e900bac29ec26476b731e62862ee9afb8f9f67225da0aa8fd1d052f8183fL91-R91),
[link](https://github.com/radius-project/radius/pull/6543/files?diff=unified&w=0#diff-197beededa4d4635e30d5c9f2261671669816f2f79a661239c6e719adae5245cL76-R76),
[link](https://github.com/radius-project/radius/pull/6543/files?diff=unified&w=0#diff-197beededa4d4635e30d5c9f2261671669816f2f79a661239c6e719adae5245cL120-R120),
[link](https://github.com/radius-project/radius/pull/6543/files?diff=unified&w=0#diff-197beededa4d4635e30d5c9f2261671669816f2f79a661239c6e719adae5245cL170-R170),
[link](https://github.com/radius-project/radius/pull/6543/files?diff=unified&w=0#diff-197beededa4d4635e30d5c9f2261671669816f2f79a661239c6e719adae5245cL178-R178),
[link](https://github.com/radius-project/radius/pull/6543/files?diff=unified&w=0#diff-19c6617fdff9355dc160bf265e7efdc44ac178e0a5257bd6bd96a22dd56f1883L13-R13),
[link](https://github.com/radius-project/radius/pull/6543/files?diff=unified&w=0#diff-4b032acb8e706dca3cf78512aadf53ee8b05354e51cd46023ed550c0625b33fbL30-R30),
[link](https://github.com/radius-project/radius/pull/6543/files?diff=unified&w=0#diff-249f8bd9306e70973e9be368bd00278a34edbd36f9bf56ea037acfc8c59583f5L22-R22))

Signed-off-by: willdavsmith <[email protected]>

docs/contributing/contributing-code/contributing-code-control-plane/configSettings.md

@@ -88,7 +88,7 @@ The following are properties that can be specified for UCP:
 | host | Domain name of the server | `0.0.0.0` |
 | port | HTTP port | `8080` |
 | pathBase | HTTPRequest PathBase | `""` |
-| authType | The environmnet authentification type (e.g. client ceritificate, etc) |`ClientCertificate` |
+| authType | The environment authentication type (e.g. client ceritificate, etc) |`ClientCertificate` |
 | armMetadataEndpoint | Endpoint that provides the client certification | `https://admin.api-dogfood.resources.windows-int.net/metadata/authentication?api-version=2015-01-01` |
 | enableArmAuth | If set, the ARM client authentifictaion is performed (must be `true`/`false`) | `true` |
 

docs/contributing/contributing-code/contributing-code-reviewing/README.md

@@ -73,7 +73,7 @@ Our expectations for code style and linting are described in our [coding documen
 
 Beyond this we value consistency with the decisions we've already made. Ideally the code we write is consistent everywhere. Failing that, it should be consistent with the surrounding components.
 
-Outside of these expectations, please feel free to make style suggestions if you think the code could be clearer. If the submitter has a good reason for doing it the way they are, and rejects your feedback then please consider: *"Is someone credibly going to make a mistake in the future based on this decision?"* before continuing to push the issue. We want the project to be approachable for new contributors (both new to Go and new to Radius). We do not want to frustrate people with unneccesary ceremony.
+Outside of these expectations, please feel free to make style suggestions if you think the code could be clearer. If the submitter has a good reason for doing it the way they are, and rejects your feedback then please consider: *"Is someone credibly going to make a mistake in the future based on this decision?"* before continuing to push the issue. We want the project to be approachable for new contributors (both new to Go and new to Radius). We do not want to frustrate people with unneccessary ceremony.
 
 The bar is **very high** for adopting new rules or changing style guidance for the project. Please start a discussion **outside** of the context of a pull-request if you think we need to adopt a new rule.
 
@@ -117,7 +117,7 @@ Review feedback for design should focus on the following points:
 
 ---
 
-Go is a pragmatic and simple language and our designs should leverage its simplicity. In general we want to avoid complex hierarchies or object-orientied abstractions where possible. The flip-side of this is that because Go is a simple language, the type system and what it can express is limited.
+Go is a pragmatic and simple language and our designs should leverage its simplicity. In general we want to avoid complex hierarchies or object-oriented abstractions where possible. The flip-side of this is that because Go is a simple language, the type system and what it can express is limited.
 
 Where possible we want to optimize for correctness, testability, and simplicity in that order. 
 
@@ -167,15 +167,15 @@ More details about those roles can be found in the [community repo](https://gith
 
 ### Responsibilities of an approver
 
-Approvers are expected to display good judgement, responsiblity, and competance over the *top* of the code review pyramid (Style, Correctness, Design).
+Approvers are expected to display good judgement, responsibility, and competance over the *top* of the code review pyramid (Style, Correctness, Design).
 
 It's likely that for for small changes a maintainer will delegate responsibility for approval to a maintainer working in the relevant area.
 
 Approvers are responsible for enforcing the **completeness** of a change. Each pull-request that is merged to `main` must stand on its own merits. We do not allow a submitter to merge and then "follow up" to complete the work (for example merging a change without tests). If you encounter this situation, **DO NOT** merge the pull-request, ask the submitter to complete the work. If they are unable to do so, then it is appropriate to close the pull-request without merging.
 
 ### Responsibilities of a maintainer
 
-Maintainers are expected to display good judgement, responsiblity, and competance over **all** of the code review pyramid, with special emphasis on Behavior and Scope. Maintainers are responsible for the technical oversight of the project, and this often means saying **"no"** when a feature request is out of scope, or a change is too complex to maintain.
+Maintainers are expected to display good judgement, responsibility, and competance over **all** of the code review pyramid, with special emphasis on Behavior and Scope. Maintainers are responsible for the technical oversight of the project, and this often means saying **"no"** when a feature request is out of scope, or a change is too complex to maintain.
 
 Maintainers are explicitly required to review and approve new dependencies to the project.
 

docs/contributing/contributing-code/contributing-code-writing/README.md

@@ -10,7 +10,7 @@ For learning Go, we recommend the following resources:
 
 - [Tour of Go](https://go.dev/tour/welcome/1)
 - [Effective Go](https://go.dev/doc/effective_go)
-- [Offical tutorials](https://go.dev/doc/)
+- [Official tutorials](https://go.dev/doc/)
 
 We're happy to accept pull-requests and give code review feedback aimed at newbies. If you have programmed in other languages before, we are confident you can pick up Go and start contributing easily.
 

docs/contributing/contributing-releases/README.md

@@ -27,7 +27,7 @@ In the project-radius/samples repo, run the [Test Quickstarts](https://github.co
 
 > For now, this is a manual task. Soon, this workflow will be triggered automatically.
 
-> There is a possiblity that the workflow run failed from flaky tests. Try re-running, and if the failure is persistent, then there should be further investigation.
+> There is a possibility that the workflow run failed from flaky tests. Try re-running, and if the failure is persistent, then there should be further investigation.
 
 If this workflow run fails, or if we encounter an issue with an RC release, please refer to "Patching" below.
 

docs/ucp/code_walkthrough.md

@@ -19,7 +19,7 @@ For proxying requests to the AWS plane, UCP needs to perform request translation
 <br/><br/>
 
 ## UCP Resource Definitions
-The swagger defintions for UCP resources are defined in swagger/specification/ucp/resource-manager/UCP/preview/2023-10-01-preview/ucp.json.
+The swagger defination for UCP resources are defined in swagger/specification/ucp/resource-manager/UCP/preview/2023-10-01-preview/ucp.json.
 
 <br/><br/>