ibc: compute IBC heights from revision number derived by chain id

[avahowell]

Previously, we hardcoded 0 when constructing IBCHeights (which consist of a revision number, and revision height) to verify that counterparties committed correct penumbra consensus states. This PR instead computes the revision number from the chain ID.

There is an underlying issue here, which is that ibc-go enforces a relationship between the chain ID and the revision number. The revision number is always parsed from the chain ID, matching with a regex that matches chain ids in the form .*[^\n-]-{1}[1-9][0-9]. If the matching fails, the revision number is assumed to be zero. This is why, despite our chain ID not fitting this regex, our handshakes worked.

In the future, we can either

• keep non-ibcgo-standard chain IDs, and commit to app_version (revision number) always being zero

or

• amend chain IDs to fit this format, eg penumbra-testnet-dione-1

[erwanor]

I think we can drop the revision number suffix, and default to zero. My understanding is that its purpose is to disambiguate block numbers for chains that do height-reseting upgrades.