feat(simapp): move genesis related commands under one genesis command (#14149)

docs/architecture/adr-041-in-place-store-migrations.md

@@ -14,7 +14,7 @@ This ADR introduces a mechanism to perform in-place state store migrations durin
 
 ## Context
 
-When a chain upgrade introduces state-breaking changes inside modules, the current procedure consists of exporting the whole state into a JSON file (via the `simd export` command), running migration scripts on the JSON file (`simd migrate` command), clearing the stores (`simd unsafe-reset-all` command), and starting a new chain with the migrated JSON file as new genesis (optionally with a custom initial block height). An example of such a procedure can be seen [in the Cosmos Hub 3->4 migration guide](https://github.com/cosmos/gaia/blob/v4.0.3/docs/migration/cosmoshub-3.md#upgrade-procedure).
+When a chain upgrade introduces state-breaking changes inside modules, the current procedure consists of exporting the whole state into a JSON file (via the `simd export` command), running migration scripts on the JSON file (`simd genesis migrate` command), clearing the stores (`simd unsafe-reset-all` command), and starting a new chain with the migrated JSON file as new genesis (optionally with a custom initial block height). An example of such a procedure can be seen [in the Cosmos Hub 3->4 migration guide](https://github.com/cosmos/gaia/blob/v4.0.3/docs/migration/cosmoshub-3.md#upgrade-procedure).
 
 This procedure is cumbersome for multiple reasons:
 
@@ -155,7 +155,7 @@ While modules MUST register their migration functions when bumping ConsensusVers
 
 ### Neutral
 
-* The Cosmos SDK will continue to support JSON migrations via the existing `simd export` and `simd migrate` commands.
+* The Cosmos SDK will continue to support JSON migrations via the existing `simd export` and `simd genesis migrate` commands.
 * The current ADR does not allow creating, renaming or deleting stores, only modifying existing store keys and values. The Cosmos SDK already has the `StoreLoader` for those operations.
 
 ## Further Discussions

docs/docs/run-node/01-run-node.md

@@ -79,7 +79,7 @@ Before starting the chain, you need to populate the state with at least one acco
 Now that you have created a local account, go ahead and grant it some `stake` tokens in your chain's genesis file. Doing so will also make sure your chain is aware of this account's existence:
 
 ```bash
-simd add-genesis-account $MY_VALIDATOR_ADDRESS 100000000000stake
+simd genesis add-genesis-account $MY_VALIDATOR_ADDRESS 100000000000stake
 ```
 
 Recall that `$MY_VALIDATOR_ADDRESS` is a variable that holds the address of the `my_validator` key in the [keyring](./00-keyring.md#adding-keys-to-the-keyring). Also note that the tokens in the Cosmos SDK have the `{amount}{denom}` format: `amount` is is a 18-digit-precision decimal number, and `denom` is the unique token identifier with its denomination key (e.g. `atom` or `uatom`). Here, we are granting `stake` tokens, as `stake` is the token identifier used for staking in [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/main/simapp). For your own chain with its own staking denom, that token identifier should be used instead.
@@ -88,10 +88,10 @@ Now that your account has some tokens, you need to add a validator to your chain
 
 ```bash
 # Create a gentx.
-simd gentx my_validator 100000000stake --chain-id my-test-chain --keyring-backend test
+simd genesis gentx my_validator 100000000stake --chain-id my-test-chain --keyring-backend test
 
 # Add the gentx to the genesis file.
-simd collect-gentxs
+simd genesis collect-gentxs
 ```
 
 A `gentx` does three things:
@@ -103,7 +103,7 @@ A `gentx` does three things:
 For more information on `gentx`, use the following command:
 
 ```bash
-simd gentx --help
+simd genesis gentx --help
 ```
 
 ## Configuring the Node Using `app.toml` and `config.toml`