chore: fix several minor typos (#18660)

docs/spec/SPEC_MODULE.md

@@ -24,7 +24,7 @@ specifications for modules. The following list is nonbinding and all sections ar
 
 * `# {Module Name}` - overview of the module
 * `## Concepts` - describe specialized concepts and definitions used throughout the spec
-* `## State` - specify and describe structures expected to marshalled into the store, and their keys
+* `## State` - specify and describe structures expected to be marshalled into the store, and their keys
 * `## State Transitions` - standard state transition operations triggered by hooks, messages, etc.
 * `## Messages` - specify message structure(s) and expected state machine behaviour(s)
 * `## Begin Block` - specify any begin-block operations

docs/spec/SPEC_STANDARD.md

@@ -42,7 +42,7 @@ This section should include an assumptions sub-section if any, the mandatory pro
 This is the main section of the document, and should contain protocol documentation, design rationale, required references, and technical details where appropriate.
 The section may have any or all of the following sub-sections, as appropriate to the particular specification. The API sub-section is especially encouraged when appropriate.
 
-* *API* - A detailed description of the features's API.
+* *API* - A detailed description of the feature's API.
 * *Technical Details* - All technical details including syntax, diagrams, semantics, protocols, data structures, algorithms, and pseudocode as appropriate. The technical specification should be detailed enough such that separate correct implementations of the specification without knowledge of each other are compatible.
 * *Backwards Compatibility* - A discussion of compatibility (or lack thereof) with previous feature or protocol versions.
 * *Known Issues* - A list of known issues. This sub-section is specially important for specifications of already in-use features.

docs/spec/store/README.md

@@ -29,7 +29,7 @@ with, which also provides the basis of most state storage and commitment operati
 is the `KVStore`. The `KVStore` interface provides basic CRUD abilities and
 prefix-based iteration, including reverse iteration.
 
-Typically, each module has it's own dedicated `KVStore` instance, which it can
+Typically, each module has its own dedicated `KVStore` instance, which it can
 get access to via the `sdk.Context` and the use of a pointer-based named key --
 `KVStoreKey`. The `KVStoreKey` provides pseudo-OCAP. How a exactly a `KVStoreKey`
 maps to a `KVStore` will be illustrated below through the `CommitMultiStore`.
@@ -42,7 +42,7 @@ until `Commit()` is called on the `CommitMultiStore`.
 
 ### `CommitMultiStore`
 
-The `CommitMultiStore` interface exposes the the top-level interface that is used
+The `CommitMultiStore` interface exposes the top-level interface that is used
 to manage state commitment and storage by an SDK application and abstracts the
 concept of multiple `KVStore`s which are used by multiple modules. Specifically,
 it supports the following high-level primitives:
@@ -53,7 +53,7 @@ it supports the following high-level primitives:
 * Allows for loading state storage at a particular height/version in the past to
   provide current head and historical queries.
 * Provides the ability to rollback state to a previous height/version.
-* Provides the ability to to load state storage at a particular height/version
+* Provides the ability to load state storage at a particular height/version
   while also performing store upgrades, which are used during live hard-fork
   application state migrations.
 * Provides the ability to commit all current accumulated state to disk and performs