docs: replace Tendermint references in docs with CometBFT (#15339)

Co-authored-by: Julien Robert <julien@rbrt.fr>

docs/spec/README.md

@@ -19,7 +19,7 @@ block.
 
 Go the [module directory](https://github.com/cosmos/cosmos-sdk/blob/main/x/README.md)
 
-## Tendermint
+## CometBFT
 
 For details on the underlying blockchain and p2p protocols, see
-the [Tendermint specification](https://github.com/tendermint/spec/tree/master/spec).
+the [CometBFT specification](https://github.com/cometbft/cometbft/tree/main/spec).

docs/spec/_ics/ics-030-signed-messages.md

@@ -8,7 +8,7 @@
 * [Specification](#specification)
 * [Future Adaptations](#future-adaptations)
 * [API](#api)
-* [References](#references)
+* [References](#references)  
 
 ## Status
 
@@ -54,16 +54,16 @@ of bytes and verification of a signature respectively.
 
 Note, our goal here is not to provide context and reasoning about why necessarily
 these algorithms were chosen apart from the fact they are the defacto algorithms
-used in Tendermint and the Cosmos SDK and that they satisfy our needs for such
+used in CometBFT and the Cosmos SDK and that they satisfy our needs for such
 cryptographic algorithms such as having resistance to collision and second
 pre-image attacks, as well as being [deterministic](https://en.wikipedia.org/wiki/Hash_function#Determinism) and [uniform](https://en.wikipedia.org/wiki/Hash_function#Uniformity).
 
 ## Specification
 
-Tendermint has a well established protocol for signing messages using a canonical
-JSON representation as defined [here](https://github.com/tendermint/tendermint/blob/master/types/canonical.go).
+CometBFT has a well established protocol for signing messages using a canonical
+JSON representation as defined [here](https://github.com/cometbft/cometbft/blob/master/types/canonical.go).
 
-An example of such a canonical JSON structure is Tendermint's vote structure:
+An example of such a canonical JSON structure is CometBFT's vote structure:
 
 ```go
 type CanonicalJSONVote struct {
@@ -87,7 +87,7 @@ to the Cosmos chain identifier. The user-agent should **refuse** signing if the
 `@chain_id` field does not match the currently active chain! The `@type` field
 must equal the constant `"message"`. The `@type` field corresponds to the type of
 structure the user will be signing in an application. For now, a user is only
-allowed to sign bytes of valid ASCII text ([see here](https://github.com/tendermint/tendermint/blob/master/libs/common/string.go#L61-L74)).
+allowed to sign bytes of valid ASCII text ([see here](https://github.com/cometbft/cometbft/blob/v0.37.0/libs/strings/string.go#L35-L64)).
 However, this will change and evolve to support additional application-specific
 structures that are human-readable and machine-verifiable ([see Future Adaptations](#futureadaptations)).
 

docs/spec/addresses/bech32.md

@@ -18,4 +18,4 @@ While all user facing interfaces to Cosmos software should exposed Bech32 interf
 
 To covert between other binary representation of addresses and keys, it is important to first apply the Amino encoding process before Bech32 encoding.
 
-A complete implementation of the Amino serialization format is unnecessary in most cases. Simply prepending bytes from this [table](https://github.com/tendermint/spec/blob/master/spec/blockchain/05-encoding.md#public-key-cryptography) to the byte string payload before Bech32 encoding will sufficient for compatible representation.
+A complete implementation of the Amino serialization format is unnecessary in most cases. Simply prepending bytes from this [table](https://github.com/cometbft/cometbft/blob/main/spec/blockchain/encoding.md) to the byte string payload before Bech32 encoding will sufficient for compatible representation.