Check spelling 0.0.22 (#16127)

Upgrades check-spelling to [v0.0.22](https://github.com/check-spelling/check-spelling/releases/tag/v0.0.22)

* refreshes workflow
* enables dependabot PRs to trigger CI (so that in the future you'll be
able to see breaking changes to the dictionary paths)
* refreshes metadata
* built-in handling of `\n`/`\r`/`\t` is removed -- This means that the
`patterns/0_*.txt` files can be removed.
* this specific PR includes some shim content, in
`allow/check-spelling-0.0.21.txt` -- once it this PR merges, it can be
removed on a branch and the next CI will clean out items from
`expect.txt` relating to the `\r` stuff and suggest replacement content.
* talking to the bot is enabled for forks (but not the master
repository)
* SARIF reporting is enabled for PRs w/in a single repository (not
across forks)
* In job reports, there's a summary table (space permitting) linking to
instances (this is a poor man's SARIF report)
* When a pattern splits a thing that results in check-spelling finding
an unrecognized token, that's reported with a distinct category
* When there are items in expect that not longer match anything but more
specific items do (e.g. `microsoft` vs. `Microsoft`), there's now a
specific category with help/advice
* Fancier excludes suggestions (excluding directories, file types, ...)
* Refreshed dictionaries
* The comment now links to the job summary (which includes SARIF link if
available, the details view, and a generated commit that people can use
if they're ok w/ the expect changes and don't want to run perl)

Validation
----------

1. the branch was developed in
https://github.com/check-spelling-sandbox/terminal/actions?query=branch%3Acheck-spelling-0.0.22
2. ensuring compatibility with 0.0.21 was done in
https://github.com/check-spelling-sandbox/terminal/pull/3
3. this version has been in development for a year and has quite a few
improvements, we've been actively dogfooding it throughout this period 😄

Additional Fixes
----------------
spelling: the
spelling: shouldn't
spelling: no
spelling: macos
spelling: github
spelling: fine-grained
spelling: coarse-grained

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

doc/Niksa.md

@@ -51,7 +51,7 @@ Will this UI enhancement come to other apps on Windows? Almost certainly not. Th
 
 Will we try to keep it from regressing? Yes! Right now it's sort of a manual process. We identify that something is getting slow and then we go haul out [WPR](https://docs.microsoft.com/en-us/windows-hardware/test/wpt/windows-performance-recorder) and start taking traces. We stare down the hot paths and try to reason out what is going on and then improve them. For instance, in the last cycle or two, we focused on heap allocations as a major area where we could improve our end-to-end performance, changing a ton of our code to use stack-constructed iterator-like facades over the underlying request buffer instead of translating and allocating it into a new heap space for each level of processing. 
 
-As an aside, @bitcrazed wants us to automate performance tests in some conhost specific way, but I haven't quite figured out a controlled environment to do this in yet. The Windows Engineering System runs performance tests each night that give us a coarse grained way of knowing if we messed something up for the whole operating system, and they technically offer a fine grained way for us to insert our own performance tests... but I just haven't got around to that yet. If you have an idea for a way for us to do this in an automated fashion, I'm all ears.
+As an aside, @bitcrazed wants us to automate performance tests in some conhost specific way, but I haven't quite figured out a controlled environment to do this in yet. The Windows Engineering System runs performance tests each night that give us a coarse-grained way of knowing if we messed something up for the whole operating system, and they technically offer a fine-grained way for us to insert our own performance tests... but I just haven't got around to that yet. If you have an idea for a way for us to do this in an automated fashion, I'm all ears.
 
 If there's anything else you'd like to know, let me know. I could go on all day. I deleted like 15 tangents from this reply before posting it.... 
 

doc/specs/drafts/#2634 - Broadcast Input/#2634 - Broadcast Input.md

@@ -290,7 +290,7 @@ though. **I recommend we ignore this for now, and leave this as a follow-up**.
 For reference, refer to the following from iTerm2:
 ![image](https://user-images.githubusercontent.com/2578976/64075757-fa971980-ccee-11e9-9e44-47aaf3bca76c.png)
 
-We don't have a menu bar like on MacOS, but we do have a tab context menu. We
+We don't have a menu bar like on macOS, but we do have a tab context menu. We
 could add these items as a nested entry under each tab. If we wanted to do this,
 we should also make sure to dynamically change the icon of the MenuItem to
 reflect the current broadcast state.

doc/specs/drafts/#3327 - Application Theming/#3327 - Application Theming.md

@@ -373,7 +373,7 @@ changes, or the active pane in a tab changes:
       `TabRowControl` to match.
 
 The `tab.cornerRadius` might be a bit trickier to implement. Currently, there's
-not a XAML resource that controls this, nor is this something that's exposed by
+no XAML resource that controls this, nor is this something that's exposed by
 the TabView control. Fortunately, this is something that's exposed to us
 programmatically. We'll need to manually set that value on each `TabViewItem` as
 we create new tabs. When we reload settings, we'll need to make sure to come