EPIC: Permissionless ICS

[insumity]

Problem

This is a meta issue to track the work of Permissinoless ICS. Permissionless ICS allows Opt In consumer chains to join ICS by simply issuing transactions, without having to go through a governance proposal.

Task list

### Introduce new messages
- [ ] new `MsgRegisterConsumer` and `MsgInitializeConsumer` messages
- [ ] Add cost for `MsgRegisterConsumer` (probably similar to gov proposals but without the refund)
- [ ] rename `MsgConsumerModification` and `MsgConsumerRemoval` to `MsgUpdateConsumer` and `MsgRemoveConsumer` respectively and augment them appropriately (e.g., introduce `owner_address` in `MsgUpdateConsumer`)

### Re-key state
- [ ] change all messages by renaming `chainId` to `consumerId` and use accordingly but make sure the error mesasges point out that `consumerId` is now needed (e.g., all previously working `MsgOptIn` messages would now fail because there's no consumer chain with a `stride-1` `consumerId`)
- [ ] fix (and add new) unit/integration/E2E tests refactored to take into account `consumerId` instead of `chainId`

### Introduce new state
- [ ] `consumerId` counter stores somewhere that is never recycled and always increments
- [ ] (`consumerId` to `chainId`) needed for misbehavior evidence (e.g., `HandleConsumerDoubleVoting`)
- [ ] (`clientId` to `consumerId`) to be able to find the right consumer chain when setting up a channel, etc.
- [ ] potentially additional state for the phase of a consumer chain, e.g., whether it's registered, initialized, etc. so that instead of doing `GetConsumerClientId( ...)` to check if a chain has launched, we have something akin `IsLaunched(...)`
- [ ] add `owner_address` for each consumer state

### Deprecate proposals
- [ ] deprecate legacy consumer proposals. Specifically, deprecate `ConsumerAdditionProposal` which means getting rid of `ConsumerAdditionProposal`s and using just the `conumserId`s instead that flow around (e.g., when checking which chain to launch)
- [ ] change proposals to have `MsgInitializeConsumer and MsgUpdateConsumer`
- [ ] deprecate `MsgConsumerAddition` and replace with a proposal that contains both `MsgInitializeConsumer` and `MsgUpdateConsumer`

### Modify relayer (optional)
- [ ] contact Hermes to use the `consumerId` instead of the `chainId` for misbheavior messages
- [ ] introduce query that given `clientId` returns the `consumerId` (see above on new state)

### Migrate
- [ ] migrate the state of already-launched consumer chains
- [ ] make sure ongoing `ConsumerAdditionProposals` get migrated as well

### Test
- [ ] think of test scenarios (similar to the _Inactive Validators_ work - see [`docs/docs/adrs/adr-017-allowing-inactive-validators.md`](https://github.com/cosmos/interchain-security/pull/2079/files#diff-0ee2f33a35fab71662e82ab7003d56cd13c05103e760918a48d7c44cfdd9f97c)) and implement those (e.g., existing consumer chain keeps working, etc.)
- [ ] give test scenarios to Hypha (i.e., things that could wrong, things to verify)
- [ ] test all queries work with `consumerId`s if they used `chainId`s previously
- [ ] verify we have checks on all the new fields that messages introduced (see [here](https://informalsystems.slack.com/archives/C055LKX623Z/p1722414960567829?thread_ts=1721998175.172089&cid=C055LKX623Z))

### Write docs
- [ ] Write ICS docs [here](https://cosmos.github.io/interchain-security/) on Permissionless

### Potpourri (so we do not forget)
- [ ] Add hooks on the gov proposals to change owner. If proposal fails, owner should move back to the original one.
- [ ] You should not be able to opt in to the different chains with the same `chainId` (add this in the ADR as well)
- [ ] Search for `TODO (PERMISSIONLESS)` before cutting this