Fix typos (cosmos#5422)

* fix typos bug-report.md

* fix typos epic-tracker.md

* fix typos release-tracker.md

* fix typos PULL_REQUEST_TEMPLATE.md

* fix typos adr-001-coin-source-tracing.md

* fix typos adr-002-go-module-versioning.md

* fix typos adr-003-ics27-acknowledgement.md

* fix typos adr-006-02-client-refactor.md

* fix typos adr-008-app-caller-cbs.md

* Update adr-008-app-caller-cbs.md

* Update adr-003-ics27-acknowledgement.md

* Update bug-report.md

---------

Co-authored-by: Carlos Rodriguez <carlos@interchain.io>

.github/ISSUE_TEMPLATE/epic-tracker.md

@@ -33,7 +33,7 @@ v                     without deliberation
 
 ## QA scenarios
 
-<!-- Lists of manual QA tests that need be performed -->
+<!-- Lists of manual QA tests that need to be performed -->
 
 ## Automated e2e tests
 

.github/ISSUE_TEMPLATE/release-tracker.md

@@ -22,7 +22,7 @@ v                     without deliberation
 
 ### Backwards compatibility
 
-<!-- List of tests that need be performed with previous
+<!-- List of tests that need to be performed with previous
 versions of ibc-go to guarantee that no regression is introduced -->
 
 - [ ] [Compatibility tests](https://github.com/cosmos/ibc-go/actions/workflows/e2e-compatibility.yaml) pass for the release branch.

.github/PULL_REQUEST_TEMPLATE.md

@@ -41,7 +41,7 @@ Before we can merge this PR, please make sure that all the following items have
 checked off. If any of the checklist items are not applicable, please leave them but
 write a little note why.
 
-- [ ] Targeted PR against correct branch (see [CONTRIBUTING.md](https://github.com/cosmos/ibc-go/blob/main/docs/dev/pull-requests.md#pull-request-targeting)).
+- [ ] Targeted PR against the correct branch (see [CONTRIBUTING.md](https://github.com/cosmos/ibc-go/blob/main/docs/dev/pull-requests.md#pull-request-targeting)).
 - [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
 - [ ] Code follows the [module structure standards](https://github.com/cosmos/cosmos-sdk/blob/main/docs/build/building-modules/11-structure.md) and [Go style guide](../docs/dev/go-style-guide.md).
 - [ ] Wrote unit and integration [tests](https://github.com/cosmos/ibc-go/blob/main/testing/README.md#ibc-testing-package).

docs/architecture/adr-001-coin-source-tracing.md

@@ -26,7 +26,7 @@ to the receiving chain through IBC TAO logic. It is expected that the
 receiving chain will mint vouchers to the receiving address.
 
 2. Sender chain is acting as the sink zone. The coins (vouchers) are burned
-on the sender chain and then transferred to the receiving chain though IBC
+on the sender chain and then transferred to the receiving chain through IBC
 TAO logic. It is expected that the receiving chain, which had previously
 sent the original denomination, will unescrow the fungible token and send
 it to the receiving address.

docs/architecture/adr-002-go-module-versioning.md

@@ -30,7 +30,7 @@ For example, changing the go package version from `v2` to `v3` bumps the import
 If the Go module version is not incremented then attempting to go get a module @v3.0.0 without the suffix results in:
 `invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v3`
 
-Version validation was added in Go 1.13. This means is that in order to release a v3.0.0 git tag without a /v3 suffix on the module definition, the tag must explicitly **not** contain a go.mod file.
+Version validation was added in Go 1.13. This means that in order to release a v3.0.0 git tag without a /v3 suffix on the module definition, the tag must explicitly **not** contain a go.mod file.
 Not including a go.mod in our release is not a viable option.
 
 #### Attempting to import multiple go module versions for ibc-go

docs/architecture/adr-006-02-client-refactor.md

@@ -91,7 +91,7 @@ As @seunlanlege [states](https://github.com/cosmos/ibc-go/issues/284#issuecommen
 
 > I'm in support of these changes for 2 reasons:
 >
-> - This would allow light clients handle batch header updates in CheckHeaderAndUpdateState, for the special case of 11-beefy proving the finality for a batch of headers is much more space and time efficient than the space/time complexity of proving each individual headers in that batch, combined.
+> - This would allow light clients to handle batch header updates in CheckHeaderAndUpdateState, for the special case of 11-beefy proving the finality for a batch of headers is much more space and time efficient than the space/time complexity of proving each individual headers in that batch, combined.
 >
 > - This also allows for a single light client instance of 11-beefy be used to prove finality for every parachain connected to the relay chain (Polkadot/Kusama). We achieve this by setting the appropriate ConsensusState for individual parachain headers in CheckHeaderAndUpdateState