[ICS02] Allow zero Height creation, but keep the H>0 condition for CometBFT clients

[Farhad-Shabani]

Problem Statement

• Client-specific condition
  As for the new Height creation (here) it isn’t allowed to create a zero height and this height >0 is a client-specific condition. Looking into the links provided here It is required for CometBFT-based chains)

• Not in conflict with ICS02
  This condition is not clearly outlined in ICS07, though should be added there. But ICS02 explicitly requires to have a zero element for the Height type which is not in conflict with having H>0 for the CometBFT clients:

  There must also be a zero-element for a height type, referred to as 0, which is less than all non-zero heights.

• Error handling side effect
  Upon converting a proto zero height, we have to deal with the zero-height error variant (ClientError::InvalidHeight) which is only needed for ICS07-related codes. And, in the places we have to observe H>0, this error is mapped to a different type and even left unwrap() like e.g. here & here & here & here

• Benefit from Option<Height>
  Living in Rust, using Option and converting to None would be more efficient, where a proto zero height means the absence of height, while still allowing zero height creation. (As also suggested in Packet.timeoutHeight should have type Option<Height> (or equivalent) ibc#776)

Related Context

• This issue caught my eye upon testing the client creation process with frozen_height = 0 in PR Disallow creation of new Tendermint client state instance with a frozen height #602.
  To create a valid not-frozen client, the frozen_height within the proto message is set to 0, but upon converting to a domain Height, it turns to an unacceptable value. So we have to manage it by turning a Result to Option via .ok() method

Acceptance Criteria

Allow zero Height creation, but keep the H>0 condition for CometBFT clients (be efficient to handle that only where we really care about not having a zero height.)

[mina86]

Related problem is that there’s no infallible way to create Height
from ClientConsensusStatePath since the latter stores height as two
u64s. I’ve looked into changing ClientConsensusStatePath definition
to be:

pub struct ClientConsensusStatePath {
    pub client_id: ClientId,
    pub height: Height,
}

This can be done without affecting serde serialisation (so that
wouldn’t be an issue) though of course it would be API-breaking
change.

PR with that change at #968