Properly handle timeouts and packet sequence numbers on ORDERED channels

[jtieri]

Currently we do not differentiate between ORDERED and UNORDERED channels when handling timeouts in the relayer.

ORDERED channels require a proof of NextSequenceRecv since the invariance on ordered channels says "if packet sequence n times out, then a packet at sequence k > n cannot be received" as per ibc-go docs.

UNORDERED channels require a proof of non-existence via the packet receipt.

This PR in it's final form will address the timeout issue as well as how packet sequences need to be handled on ORDERED channels but will be missing the logic for finishing the channel handshake process which is necessary for full interchain account support. Ideally we will be querying for recent txs and then looking for ChannelOpenInit in the events. If we noticed a ChannelOpenInit event then the relayer will attempt to finish the channel handshake.

Right now we are waiting for two upstream changes which emit the version information in ChannelOpenInit. This is needed to parse the full channel information from the events.

cosmos/ibc-go#1203
cosmos/ibc-go#1204

Closes #321

[jtieri]

This PR has been tested using the interchain accounts demo here

To test with this branch checkout commit hash b92f1de and make install the relayer. Then clone down the aforementioned interchain accounts demo and run make init-golang-rly

You should see a interchain account successfully registered, a packet successfully relayed and then a successfully timed out packet.

Not an ideal way to test this but I had started adding these test cases to the IBC-test-framework and then fudged my branch so will have to reimplement this there.

[mark-rushakoff]

I skimmed through the change this morning and everything looks correct AFAICS.

[jtieri]

Addressed the few suggestions, this should be gtm.

[jackzampolin]

SHIPPING