Better handle data de-serialization for custom chains

[RiccardoM]

Feature description

Currently in order to properly parse the transaction messages, Juno de-serializes the data using the Cosmos SDK types, particularly the sdk.Msg interface. Although this works, it requires a lot of work when dealing with custom chains: to properly deserialize an sdk.Msg instance, the various implementations must be registered within the used codec instance. This often requires Juno to be forked and use the custom chain code as a dependency (since sdk.Msg instances are registered in the provided codec instance there). This makes it hard to maintain future versions of Juno, since more and more chains will most likely use their custom messages and thus more and more forks need to be created.

Implementation proposal

To fix this issue, we can attempt defining our own Transaction and Message instance with custom de-serialization. Such instances should contain only the values that we are interested in reading for our purposes, and nothing more. Then, we leave the various modules with the burden of de-serializing the original transaction/message bytes to whatever type they want if needed.