Docs improvements (#6746)

* fix adr-009-v6-ics27-msgserver.md

* fix adr-015-ibc-packet-receiver.md

* fix adr-026-ibc-client-recovery-mechanisms.md

* fix adr-027-ibc-wasm.md

* fix adr.template.md

docs/architecture/adr-009-v6-ics27-msgserver.md

@@ -12,13 +12,13 @@ Accepted, implemented in v6 of ibc-go
 
 ICS 27 (Interchain Accounts) brought a cross-chain account management protocol built upon IBC.
 It enabled chains to programmatically create accounts on behalf of counterparty chains which may enable a variety of authentication methods for this interchain account.
-The initial release of ICS 27 focused on enabling authentication schemes which may not require signing with a private key, such as via on-chain mechanisms like governance.
+The initial release of ICS 27 focused on enabling authentication schemes that may not require signing with a private key, such as via on-chain mechanisms like governance.
 
 Following the initial release of ICS 27 it became evident that:
 
 - a default authentication module would enable more usage of ICS 27
 - generic authentication modules should be capable of authenticating an interchain account registration
-- application logic which wraps ICS 27 packet sends do not need to be associated with the authentication logic
+- application logic which wraps ICS 27 packet sends does not need to be associated with the authentication logic
 
 ## Decision
 

docs/architecture/adr-015-ibc-packet-receiver.md

@@ -10,7 +10,7 @@
 
 In ICS 26, the routing module is defined as a layer above each application module
 which verifies and routes messages to the destination modules. It is possible to
-implement it as a separate module, however, we already have functionality to route
+implement it as a separate module, however, we already have the functionality to route
 messages upon the destination identifiers in the baseapp. This ADR suggests
 to utilize existing `baseapp.router` to route packets to application modules.
 

docs/architecture/adr-026-ibc-client-recovery-mechanisms.md

@@ -18,7 +18,7 @@
 
 ### Summary
 
-At launch, IBC will be a novel protocol, without an experienced user-base. At the protocol layer, it is not possible to distinguish between client expiry or misbehaviour due to genuine faults (Byzantine behavior) and client expiry or misbehaviour due to user mistakes (failing to update a client, or accidentally double-signing). In the base IBC protocol and ICS 20 fungible token transfer implementation, if a client can no longer be updated, funds in that channel will be permanently locked and can no longer be transferred. To the degree that it is safe to do so, it would be preferable to provide users with a recovery mechanism which can be utilised in these exceptional cases.
+At launch, IBC will be a novel protocol, without an experienced user-base. At the protocol layer, it is not possible to distinguish between client expiry or misbehaviour due to genuine faults (Byzantine behaviour) and client expiry or misbehaviour due to user mistakes (failing to update a client, or accidentally double-signing). In the base IBC protocol and ICS 20 fungible token transfer implementation, if a client can no longer be updated, funds in that channel will be permanently locked and can no longer be transferred. To the degree that it is safe to do so, it would be preferable to provide users with a recovery mechanism which can be utilised in these exceptional cases.
 
 ### Exceptional cases
 

docs/architecture/adr-027-ibc-wasm.md

@@ -29,7 +29,7 @@ client is part of its codebase), re-build chains' binaries, pass a governance pr
 
 Another problem stemming from the above process is that if a chain wants to upgrade its own consensus, it will 
 need to convince every chain or hub connected to it to upgrade its light client in order to stay connected. Due 
-to the time consuming process required to upgrade a light client, a chain with lots of connections needs to be 
+to the time-consuming process required to upgrade a light client, a chain with lots of connections needs to be 
 disconnected for quite some time after upgrading its consensus, which can be very expensive in terms of time and effort.
 
 We are proposing simplifying this workflow by integrating a Wasm light client module that makes adding support for

docs/architecture/adr.template.md

@@ -12,7 +12,7 @@
 
 ## Context
 
-> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution.
+> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high-level idea behind the solution.
 
 ## Decision