Provide a "upgrade client proposal" handler for Tendermint chains

[Farhad-Shabani]

Problem Definition

The work done so far and covered within ADR06 around upgrading a counterparty client mainly reflects how to handle submitted MsgUpgradeClient by the relayer and substitute the upgraded client and consensus states on the counterparty chain.
But, there is another side to this process (see ibc-go) and it is where the newly proposed client and consensus states should be stored in the upgrade path (related to #141) of the upgrading chain.
We haven't clarified yet how the incoming chain-level upgrade proposal should be handled within the IBC-rs core and a specific implementation for Tendermint chains seems to be necessary.

[Farhad-Shabani]

Updates

• We cannot assume about how hosts may reach a consensus on upgrading a client, which could be via a governance model, multi-sig, etc. Accordingly, we can’t write a generic UpgradeProposal handler.
• The minimum we should do is expose getter/setter APIs under our context traits, so hosts can store and retrieve upgraded client/consensus states in/from UpgradeClientPath
• For Comet-based chains, we might be able to code a very similar operation to IBC-go and maintain it within IBC-rs as some ready-to-use functions. But we'd have to add a minimal gov module to basecoin-rs first. (Blocked)