Fix incorrect case/capitalization in ref docs

This ensures the following components have the correct/consistent case
throughout the reference documentation:

Preference variable, PS environment variable, PS drive, PS provider,
PS command name, PS command argument, PS module, PS file extension,
PS host name/application, #Requires statement, parameter name,
about_* topic, member name, scope modifier, keyword, operator,
calculated property key/value, attribute, type accelerator,
type literal/name, WMI namespace/class, variable name,
special character, comment-based help keyword, product/company name,
Windows drive letter/directory, Windows/Unix environment variable

In addition, changes include fixes to incorrect terminology (e.g.,
referring to a keyword as a command) and formatting of PS syntax
elements (non-exhaustive).

Author: surfingoldelephant

reference/docs-conceptual/community/2021-updates.md

@@ -258,7 +258,7 @@ New content
 
 Content updates
 
-- Converted [about_remote_faq](/powershell/scripting/learn/remoting/powershell-remoting-faq) to new
+- Converted [about_Remote_FAQ](/powershell/scripting/learn/remoting/powershell-remoting-faq) to new
   YAML format and moved to conceptual TOC
 - Moved **PSDesiredStateConfiguration** out of 7.2 docs and into PowerShell-Docs-Modules
   - DSC is being removed from PowerShell to become an optional module that is loaded from the

reference/docs-conceptual/community/community-update.yml

@@ -8,7 +8,7 @@ metadata:
   description: A list of resources and a summary of new articles and community contributions. # < 160 chars
   ms.topic: landing-page # Required
   author: sdwheeler #Required; your GitHub user alias, with correct capitalization.
-  ms.author: sewhee #Required; microsoft alias of author; optional team alias.
+  ms.author: sewhee #Required; Microsoft alias of author; optional team alias.
   ms.date: 02/03/2025
 
 # linkListType: architecture | concept | deploy | download | get-started | how-to-guide | learn |

reference/docs-conceptual/community/contributing/labelling-in-github.md

@@ -54,7 +54,7 @@ Area labels identify the parts of PowerShell or the documentation that the issue
 | `area-portability`       | Cross-platform compatibility.                                                            |
 | `area-powershellget`     | The [PowerShellGet][13] module.                                                          |
 | `area-providers`         | PowerShell providers.                                                                    |
-| `area-psreadline`        | The [PSReadline][14] module.                                                             |
+| `area-psreadline`        | The [PSReadLine][14] module.                                                             |
 | `area-release-notes`     | The PowerShell release notes.                                                            |
 | `area-remoting`          | The PowerShell remoting feature and cmdlets.                                             |
 | `area-scriptanalyzer`    | The [PSScriptAnalyzer][15] module.                                                       |

reference/docs-conceptual/dev-cross-plat/choosing-the-right-nuget-package.md

@@ -168,7 +168,7 @@ as the root module).
 When it comes to testing your module in .NET test runners like xUnit, remember that compile-time
 checks can only go so far. You must test your module against the relevant PowerShell platforms.
 
-To test APIs built against PowerShell Standard in .NET, you should add `Microsoft.Powershell.SDK` as
+To test APIs built against PowerShell Standard in .NET, you should add `Microsoft.PowerShell.SDK` as
 a testing dependency with .NET Core (with the version set to match the desired PowerShell version),
 and the appropriate Windows PowerShell reference assemblies with .NET Framework.
 
@@ -187,24 +187,24 @@ PowerShell installations or libraries.
 > The PowerShell SDK just refers to all the component packages that make up PowerShell, and which
 > can be used for .NET development with PowerShell.
 
-A given `Microsoft.Powershell.SDK` version contains the concrete implementation of the same version
+A given `Microsoft.PowerShell.SDK` version contains the concrete implementation of the same version
 of the PowerShell application; version 7.0 contains the implementation of PowerShell 7.0 and running
 commands or scripts with it will largely behave like running them in PowerShell 7.0.
 
 Running PowerShell commands from the SDK is mostly, but not totally, the same as running them from
 `pwsh`. For example, [Start-Job][10] currently depends on the `pwsh` executable being available, and
-so will not work with `Microsoft.Powershell.SDK` by default.
+so will not work with `Microsoft.PowerShell.SDK` by default.
 
-Targeting `Microsoft.Powershell.SDK` from a .NET application allows you to integrate with all of
+Targeting `Microsoft.PowerShell.SDK` from a .NET application allows you to integrate with all of
 PowerShell's implementation assemblies, such as `System.Management.Automation`,
 `Microsoft.PowerShell.Management`, and other module assemblies.
 
-Publishing an application targeting `Microsoft.Powershell.SDK` will include all these assemblies,
+Publishing an application targeting `Microsoft.PowerShell.SDK` will include all these assemblies,
 and any dependencies PowerShell requires. It will also include other assets that PowerShell required
 in its build, such as the module manifests for `Microsoft.PowerShell.*` modules and the `ref`
 directory required by [Add-Type][11].
 
-Given the completeness of `Microsoft.Powershell.SDK`, it's best suited for:
+Given the completeness of `Microsoft.PowerShell.SDK`, it's best suited for:
 
 - Implementation of PowerShell hosts.
 - xUnit testing of libraries targeting PowerShell reference assemblies.
@@ -215,7 +215,7 @@ be used as a module or otherwise loaded by PowerShell, but depends on APIs only
 particular version of PowerShell. Note that an assembly published against a specific version of
 `Microsoft.PowerShell.SDK` will only be safe to load and use in that version of PowerShell. To
 target multiple PowerShell versions with specific APIs, multiple builds are required, each targeting
-their own version of `Microsoft.Powershell.SDK`.
+their own version of `Microsoft.PowerShell.SDK`.
 
 > [!NOTE]
 > The PowerShell SDK is only available for PowerShell versions 6 and up. To provide equivalent
@@ -225,7 +225,7 @@ their own version of `Microsoft.Powershell.SDK`.
 ## System.Management.Automation
 
 The `System.Management.Automation` package is the heart of the PowerShell SDK. It exists on NuGet,
-primarily, as an asset for `Microsoft.Powershell.SDK` to pull in. However, it can also be used
+primarily, as an asset for `Microsoft.PowerShell.SDK` to pull in. However, it can also be used
 directly as a package for smaller hosting scenarios and version-targeting modules.
 
 Specifically, the `System.Management.Automation` package may be a preferable provider of PowerShell

reference/docs-conceptual/dev-cross-plat/create-feedback-provider.md

@@ -449,7 +449,7 @@ Import-Module ./bin/Debug/net8.0/myFeedbackProvider
 ```
 
 Once you're satisfied with your module, you should create a module manifest, publish it to the
-PowerShell Gallery, and install it in your `$env:PSModulePath`. For more information, see
+PowerShell Gallery, and install it in your `$Env:PSModulePath`. For more information, see
 [How to create a module manifest][01]. You can add the `Import-Module` command to your `$PROFILE`
 script so the module is available in PowerShell session.
 

reference/docs-conceptual/dev-cross-plat/create-standard-library-binary-Module.md

@@ -282,7 +282,7 @@ At this point, we can import our module with the psd1 file.
 Import-Module ".\Output\$module\$module.psd1"
 ```
 
-From here, we can drop the `.\Output\$module` folder into our `$env:PSModulePath` directory and it
+From here, we can drop the `.\Output\$module` folder into our `$Env:PSModulePath` directory and it
 autoloads our command whenever we need it.
 
 ### Update: dotnet new PSModule