Avoid generic parameter in `CosmosMsg<C>`

[chipshort]

We still need to support the custom message feature, but having this as a generic is quite annoying for users because it has to be carried through the whole code.

In our meeting, switching to dynamic dispatch with erased_serde / typetag was proposed.

We should make sure that downstream users are not affected by the fact that this makes CosmosMsg no longer Send + Sync and that the custom message type is not necessarily Sized anymore.
This could probably be looked at for something like MultiTest.

[kulikthebird]

What are the use cases of the generic param in CosmosMsg? As far as I can see the message is added to the response of entry points handlers in smart contracts. In wasmd it is translated from CosmosMsg into []sdk.Msg by a default message encoder:

func DefaultEncoders(unpacker codectypes.AnyUnpacker, portSource types.ICS20TransferPortSource) MessageEncoders {
	return MessageEncoders{
		Bank:         EncodeBankMsg,
		Custom:       NoCustomMsg,
		Distribution: EncodeDistributionMsg,
		IBC:          EncodeIBCMsg(portSource),
		IBC2:         EncodeIBCv2Msg,
		Staking:      EncodeStakingMsg,
		Any:          EncodeAnyMsg(unpacker),
		Wasm:         EncodeWasmMsg,
		Gov:          EncodeGovMsg,
	}
}

where NoCustomMsg is defined as:

func NoCustomMsg(_ sdk.AccAddress, _ json.RawMessage) ([]sdk.Msg, error) {
	return nil, errorsmod.Wrap(types.ErrUnknownMsg, "custom variant not supported")
}

So in other words, if a given blockchain developers does not configure otherwise, smart contracts should not return custom types.

Some blockchains may use the custom msg by implementing their own encoder. The problem is that Rust's type system cannot prevent mistakes related to mismatch between the chain's custom type and the one defined in the contracts.

My proposal is to use Custom(Binary) as a custom field. Contract devs experience would change negligibly - they'd need to serialize the custom message before creating CosmosMsg::Custom. We could add a new method for that:

impl CosmosMsg {
    pub fn new_custom<T: Into<Binary>>(msg: T) -> Self {
        Self::Custom(msg.into())
    }
}

PoC: #2475

[webmaster128]

use Custom(Binary) as a custom field

This approach is reasonable, but it is pretty much what CosmosMsg::Any already does

[chipshort]

I think the benefits that CosmosMsg::Custom has over CosmosMsg::Anyare:

• some level of type safety (and chains can provide types for this in their own crates)
• uses JSON, no need to choose a Protobuf library, get protobuf definitions, etc.

With the Custom(Binary) approach, we lose the first one. And in some sense, also the second one because we no longer have any control over the encoding of the data.
This change also seems to be breaking the contract <-> VM interface, i.e. contracts that use the new way don't work on pre-3.0 chains and the other way around. If we want to solve this issue, we can break the contracts on the source level, but not this interface.

[chipshort]

Alright, so I implemented a draft in #2498 that uses dyn CustomMsg, but it requires a bit of a mess to get it working, as well as some hacky stuff, so I decided together with @DariuszDepta to leave this out of the 3.0 release for now.