Implement the actual ICS20 protocol

[DariuszDepta]

I guess, you are using a simplified version of the actual ICS-20 protocol here, but I do want to note that this is not how the denom works in the actual protocol. We will have to make changes to this if we want to implement IBC Callbacks later down the road.
Here's a quick example of how it looks on chain:
If I send ujuno from Juno to Osmosis, the denom is ujuno. If I send it back from Osmosis to Juno, it is transfer/channel-42/ujuno.
According to the spec, it's formatted as {ics20Port}/{ics20Channel}/{denom} using the source port and channel (so the ones on Osmosis in my example). To detect that, we would need to check for that prefix and remove it to get the denom on the receiving chain.
Side note: On most chains this denom is also different than what is shown to the bank module because it gets hashed with Sha256 and prefixed with ibc/

Originally posted by @chipshort in #184 (comment)

[chipshort]

Implementing the whole ICS20 protocol is probably a bit too ambitious, but ibc-rs would probably be a good thing to look at for that.

After doing some tests in wasmd, it seems that my original comment is somewhat incorrect. Here is how it should work:
The packet contains a denom, let's say "stake". This seems to be the denom on the source chain. On the destination chain, this denom then gets prefixed with "{destinationPort}/{destinationChannel}/" to avoid collisions of "stake" that came directly from the source chain and "stake" that was routed through somewhere else. So for example "transfer/channel-2/stake". In ibc-go this is then hashed with sha256 and prefixed with "ibc/", so "ibc/D549749C93524DA1831A4B3C850DFC1BA9060261BEDFB224B3B0B4744CD77A70". I think the hashing is configurable somehow, but the chains I've seen seem to have it enabled.
On the way back, this has to be undone (so the hash and its input need to be stored in a map somewhere). The packet then contains the path, e.g. transfer/channel-2/stake and the destination chain (which was the source) will detect that the denom is prefixed with what was {destinationPort}/{destinationChannel}/ in the first transfer and is now {sourcePort}/{sourceChannel}/ and will instead remove that prefix to get back to its native denom. See also this explanation in ibc-rs

Here's the corresponding code in ibc-rs for the whole receive logic.

Now, with all that being said, I think we should not go down this route because it takes a lot of effort and has a high potential for implementing it incorrectly for very little benefit.