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.~~

polkadot/roadmap/implementers-guide/src/node/approval/approval-distribution.md

@@ -101,7 +101,7 @@ struct State {
 }
 
 enum MessageFingerprint {
-  Assigment(Hash, u32, ValidatorIndex),
+  Assignment(Hash, u32, ValidatorIndex),
   Approval(Hash, u32, ValidatorIndex),
 }
 
@@ -203,7 +203,7 @@ For all peers:
   * Compute `view_intersection` as the intersection of the peer's view blocks with the hashes of the new blocks.
   * Invoke `unify_with_peer(peer, view_intersection)`.
 
-#### `ApprovalDistributionMessage::DistributeAsignment`
+#### `ApprovalDistributionMessage::DistributeAssignment`
 
 Call `import_and_circulate_assignment` with `MessageSource::Local`.
 

polkadot/roadmap/implementers-guide/src/node/availability/availability-recovery.md

@@ -115,7 +115,7 @@ On `Conclude`, shut down the subsystem.
 
 Launch the source as a background task running `run(recovery_task)`.
 
-#### `run(recovery_task) -> Result<AvailableData, RecoeryError>`
+#### `run(recovery_task) -> Result<AvailableData, RecoveryError>`
 
 ```rust
 // How many parallel requests to have going at once.

polkadot/roadmap/implementers-guide/src/node/disputes/dispute-coordinator.md

@@ -76,7 +76,7 @@ dispute is raised reconsider their vote and send an explicit invalid vote. If th
 recorded, then they could avoid a slash.
 
 This is not a problem for our basic security assumptions: The backers are the ones to be supposed to have skin in the
-game, so we are not too woried about colluding approval voters getting away slash free as the gambler's ruin property is
+game, so we are not too worried about colluding approval voters getting away slash free as the gambler's ruin property is
 maintained anyway. There is however a separate problem, from colluding approval-voters, that is "lazy" approval voters.
 If it were easy and reliable for approval-voters to reconsider their vote, in case of an actual dispute, then they don't
 have a direct incentive (apart from playing a part in securing the network) to properly run the validation function at
@@ -331,13 +331,13 @@ off-chain. The reason for this is a dispute can be raised for a candidate in a p
 validator that is going to be slashed for it might not even be in the current active set. That means it can't be
 disabled on-chain. We need a way to prevent someone from disputing all valid candidates in the previous era. We do this
 by keeping track of the validators who lost a dispute in the past few sessions and use that list in addition to the
-on-chain disabled validators state. In addition to past session misbehavior, this also heps in case a slash is delayed.
+on-chain disabled validators state. In addition to past session misbehavior, this also helps in case a slash is delayed.
 
 When we receive a dispute statements set, we do the following:
 1. Take the on-chain state of disabled validators at the relay parent block.
 1. Take a list of those who lost a dispute in that session in the order that prioritizes the biggest and newest offence.
 1. Combine the two lists and take the first byzantine threshold validators from it.
-1. If the dispute is unconfimed, check if all votes against the candidate are from disabled validators.
+1. If the dispute is unconfirmed, check if all votes against the candidate are from disabled validators.
 If so, we don't participate in the dispute, but record the votes.
 
 ### Backing Votes
@@ -591,7 +591,7 @@ Initiates processing via the `Participation` module and updates the internal sta
 
 ### On `MuxedMessage::Participation`
 
-This message is sent from `Participatuion` module and indicates a processed dispute participation. It's the result of
+This message is sent from `Participation` module and indicates a processed dispute participation. It's the result of
 the processing job initiated with `OverseerSignal::ActiveLeaves`. The subsystem issues a `DisputeMessage` with the
 result.
 

polkadot/roadmap/implementers-guide/src/node/overseer.md

@@ -108,11 +108,11 @@ way that the receiving subsystem can further address the communication to one of
 This communication prevents a certain class of race conditions. When the Overseer determines that it is time for
 subsystems to begin working on top of a particular relay-parent, it will dispatch a `ActiveLeavesUpdate` message to all
 subsystems to do so, and those messages will be handled asynchronously by those subsystems. Some subsystems will receive
-those messsages before others, and it is important that a message sent by subsystem A after receiving
+those messages before others, and it is important that a message sent by subsystem A after receiving
 `ActiveLeavesUpdate` message will arrive at subsystem B after its `ActiveLeavesUpdate` message. If subsystem A
 maintained an independent channel with subsystem B to communicate, it would be possible for subsystem B to handle the
 side message before the `ActiveLeavesUpdate` message, but it wouldn't have any logical course of action to take with the
-side message - leading to it being discarded or improperly handled. Well-architectured state machines should have a
+side message - leading to it being discarded or improperly handled. Well-architected state machines should have a
 single source of inputs, so that is what we do here.
 
 One exception is reasonable to make for responses to requests. A request should be made via the overseer in order to

polkadot/roadmap/implementers-guide/src/node/utility/pvf-prechecker.md

@@ -8,7 +8,7 @@ pre-checking. Head over to [overview] for the PVF pre-checking process overview.
 There is no dedicated input mechanism for PVF pre-checker. Instead, PVF pre-checker looks on the `ActiveLeavesUpdate`
 event stream for work.
 
-This subsytem does not produce any output messages either. The subsystem will, however, send messages to the
+This subsystem does not produce any output messages either. The subsystem will, however, send messages to the
 [Runtime API] subsystem to query for the pending PVFs and to submit votes. In addition to that, it will also
 communicate with [Candidate Validation] Subsystem to request PVF pre-check.