Move sdk.Msg and other TX stuff to types/tx

[amaury1093]

Summary

Move tx-related interfaces, structs and functions from sdk to types/tx.

ref: #10527 (comment)

Problem Definition

We use sdk.Msg everywhere, but it's probably a better idea to put it in the types/tx package, to unclutter sdk.

Proposal

• Remove sdk.Tx, sdk.FeeTx, sdk.MemoTx etc, see Move away from Tx interfaces (sdk.Tx, sdk.FeeTx...) #10347
• Move functions/interfaces that are tx-related to types/tx:
  • sdk.Msg
  • MsgTypeURL, TxEncoder, TxDecoder (the latter 2 maybe in a middleware)?
  • RegisterLegacyAminoCodec, RegisterInterfaces

If possible, create a type alias to provide backwards compatibility.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[aaronc]

Well I have a separate proposal to get rid of sdk.Msg: #10368.

For the other stuff, my preference would be a new tx/ go module rather than types/tx where all the tx stuff including what's in x/auth/tx. But maybe this is a larger disussion.

What I propose for sdk.Msg is to make ValidateBasic a generic thing and then have a proto field option cosmos.msg.v1.signer(Msg's are actually sort of independent of tx encoding which is in cosmos.tx). For now, we can leave the existing sdk.Msg as is for legacy users and the new proto field option would avoid the bech32 global issue.

[amaury1093]

Ah right. This issue was created initially as a follow-up in a PR review. Maybe let's close this for now, and create new issues once the larger proposal has been defined and accepted. Are you okay with that @fdymylja ?