Add a blanket Serialize, Deserialize impl to IBC domain types

[hdevalence]

The original ibc-rs code we forked from used #[derive(Serialize, Deserialize)] to derive serialization formats from the domain types. However, this is dangerous from an interoperability and protocol compatibility standpoint, because it means that:

1. External, long-lived interfaces (serialization formats) are derived from internal implementation details, so that changing those implementations becomes a breaking change;
2. Messages that already have defined serializations as part of the IBC specification now have a second, ad-hoc serialization only understood by Rust code -- which may happen to mostly align with the specified serialization, or may not, or may differ only in some subtle way.

To fix this, we need to ensure that:

• All Serialize and Deserialize implementations for protobuf messages always serialize through the Proto-derived serialization format (by forwarding to the ibc-proto type, which is compiled with ProtoJSON support)
• Any other Serialize and Deserialize implementations are audited and justified against some external format.

One way to do this could be to use a blanket impl on the ibc-types-domain-type DomainType crate, something that's not possible for the penumbra-proto DomainType (which has implementations on foreign types, some of which have Serialize impls already). This would ensure that any DomainType would be Serialize, and (by disallowing conflicting impls) that it was not serialized other than by conversion through a proto type.

The remaining Serialize/Deserialize impls would then be easily findable using ripgrep or some other search tool.

[hdevalence]

This is unblocked now that cosmos/ibc-proto-rs#95 landed.

[conorsch]

Much of this work has been completed via recent PR into ibc-types. Still a few more to go before we can close.

[erwanor]

This is at least partially done. In #69 and #71, we went through all (?) domain types and made sure that the serde derives forward to pbjson. What remains is removing the rest of the Serialize and Deserialize implementations in a second push. This will be done in concert with @grod220.