Fix spelling mistakes across the whole repository (#3808)

**Update:** Pushed additional changes based on the review comments.

**This pull request fixes various spelling mistakes in this
repository.**

Most of the changes are contained in the first **3** commits:

- `Fix spelling mistakes in comments and docs`

- `Fix spelling mistakes in test names`

- `Fix spelling mistakes in error messages, panic messages, logs and
tracing`

Other source code spelling mistakes are separated into individual
commits for easier reviewing:

- `Fix the spelling of 'authority'`

- `Fix the spelling of 'REASONABLE_HEADERS_IN_JUSTIFICATION_ANCESTRY'`

- `Fix the spelling of 'prev_enqueud_messages'`

- `Fix the spelling of 'endpoint'`

- `Fix the spelling of 'children'`

- `Fix the spelling of 'PenpalSiblingSovereignAccount'`

- `Fix the spelling of 'PenpalSudoAccount'`

- `Fix the spelling of 'insufficient'`

- `Fix the spelling of 'PalletXcmExtrinsicsBenchmark'`

- `Fix the spelling of 'subtracted'`

- `Fix the spelling of 'CandidatePendingAvailability'`

- `Fix the spelling of 'exclusive'`

- `Fix the spelling of 'until'`

- `Fix the spelling of 'discriminator'`

- `Fix the spelling of 'nonexistent'`

- `Fix the spelling of 'subsystem'`

- `Fix the spelling of 'indices'`

- `Fix the spelling of 'committed'`

- `Fix the spelling of 'topology'`

- `Fix the spelling of 'response'`

- `Fix the spelling of 'beneficiary'`

- `Fix the spelling of 'formatted'`

- `Fix the spelling of 'UNKNOWN_PROOF_REQUEST'`

- `Fix the spelling of 'succeeded'`

- `Fix the spelling of 'reopened'`

- `Fix the spelling of 'proposer'`

- `Fix the spelling of 'InstantiationNonce'`

- `Fix the spelling of 'depositor'`

- `Fix the spelling of 'expiration'`

- `Fix the spelling of 'phantom'`

- `Fix the spelling of 'AggregatedKeyValue'`

- `Fix the spelling of 'randomness'`

- `Fix the spelling of 'defendant'`

- `Fix the spelling of 'AquaticMammal'`

- `Fix the spelling of 'transactions'`

- `Fix the spelling of 'PassingTracingSubscriber'`

- `Fix the spelling of 'TxSignaturePayload'`

- `Fix the spelling of 'versioning'`

- `Fix the spelling of 'descendant'`

- `Fix the spelling of 'overridden'`

- `Fix the spelling of 'network'`

Let me know if this structure is adequate.

**Note:** The usage of the words `Merkle`, `Merkelize`, `Merklization`,
`Merkelization`, `Merkleization`, is somewhat inconsistent but I left it
as it is.

~~**Note:** In some places the term `Receival` is used to refer to
message reception, IMO `Reception` is the correct word here, but I left
it as it is.~~

~~**Note:** In some places the term `Overlayed` is used instead of the
more acceptable version `Overlaid` but I also left it as it is.~~

~~**Note:** In some places the term `Applyable` is used instead of the
correct version `Applicable` but I also left it as it is.~~

**Note:** Some usage of British vs American english e.g. `judgement` vs
`judgment`, `initialise` vs `initialize`, `optimise` vs `optimize` etc.
are both present in different places, but I suppose that's
understandable given the number of contributors.

~~**Note:** There is a spelling mistake in `.github/CODEOWNERS` but it
triggers errors in CI when I make changes to it, so I left it as it
is.~~

substrate/utils/substrate-bip39/README.md

@@ -21,12 +21,12 @@ to wallets providing their own dictionaries and checksum mechanism. Issues with
    to CSPRNG supplied dictionary phrases.
 
 2. Providing own dictionaries felt into the _you ain't gonna need it_ anti-pattern category on day 1. Wallet providers
-   (be it hardware or software) typically want their products to be compatibile with other wallets so that users can
+   (be it hardware or software) typically want their products to be compatible with other wallets so that users can
    migrate to their product without having to migrate all their assets.
 
 To achieve the above phrases have to be precisely encoded in _The One True Canonical Encoding_, for which UTF-8 NFKD was
 chosen. This is largely irrelevant (and even ignored) for English phrases, as they encode to basically just ASCII in
-virtualy every character encoding known to mankind, but immedietly becomes a problem for dictionaries that do use
+virtually every character encoding known to mankind, but immediately becomes a problem for dictionaries that do use
 non-ASCII characters. Even if the right encoding is used and implemented correctly, there are still [other caveats
 present for some non-english dictionaries](https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md),
 such as normalizing spaces to a canonical form, or making some latin based characters equivalent to their base in
@@ -34,8 +34,8 @@ dictionary lookups (eg. Spanish `ñ` and `n` are meant to be interchangeable). T
 headache, and opens doors for disagreements between buggy implementations, breaking compatibility.
 
 BIP39 does already provide a form of the mnemonic that is free from all of these issues: the entropy byte array. Since
-veryfing the checksum requires that we recover the entropy from which the phrase was generated, no extra work is
-actually needed here. Wallet implementators can encode the dictionaries in whatever encoding they find convenient (as
+verifying the checksum requires that we recover the entropy from which the phrase was generated, no extra work is
+actually needed here. Wallet implementors can encode the dictionaries in whatever encoding they find convenient (as
 long as they are the standard BIP39 dictionaries), no harm in using UTF-16 string primitives that Java and JavaScript
 provide. Since the dictionary is fixed and known, and the checksum is done on the entropy itself, the exact character
 encoding used becomes irrelevant, as are the precise codepoints and amount of whitespace around the words. It is thus