Change DenomMetadataById to support string-encoded asset IDs

[hdevalence]

Is your feature request related to a problem? Please describe.

Currently, the DenomMetadataByIdRequest only allows specifying an AssetId message:

// Requests information on an asset by asset id
message DenomMetadataByIdRequest {
  // The expected chain id (empty string if no expectation).
  string chain_id = 1;
  // The asset id to request information on.
  core.crypto.v1alpha1.AssetId asset_id = 2;
}

The AssetId message is defined as

message AssetId {
    bytes inner = 1;
}

so the ProtoJSON encoding has inner: "BASE64_DATA".

This makes it hard to use when looking up asset IDs from pcli or other UI, which show them formatted as a Bech32 string.

It would be much more convenient if it were possible to supply a Bech32-encoded string instead.

Describe the solution you'd like
There are three possible solutions:

1. We could add a string asset_id_str = 3; to the DenomMetadataByIdRequest, and change the semantics of the request processing to allow either specifying an AssetId message OR a bech32-encoded string.

2. We could change the definition of the AssetId message from

message AssetId {
    bytes inner = 1;
}

to

message AssetId {
    bytes inner = 1;
    string bech32 = 2;
}

3. We could change the AssetId message to encode the asset ID as a bech32 string inside the proto.

Option (2) is effectively like (1), but instead of solving the problem just for the DenomMetadataByIdRequest, we allow bech32 encoding anywhere we use the AssetId. This is much more flexible, but it has at least two downsides:

• it means every proto consumer has to be prepared to parse Bech32 data, and that parsing can't be done with the proto-generated code -- or else the bech32 encoding may be a "second class" encoding not supported by all tooling (how bad is that, exactly?);
• it means that parsers have to correctly handle a situation where an attacker supplies different data as bytes and as a string, and attempts to confuse the parser -- rejecting messages where both are set doesn't seem particularly onerous, but it is a new bug surface area.

Option (3) has a similar downside to (2), in that consumers now have to handle bech32 data, but it's less severe, because they can just consistently pass strings around. On the other hand, it has a significant downside that when using the binary proto encoding, we're encoding bytes as a bech32 string rather than the actual binary data, so we now bloat the size of every single message that ever contains an AssetId, which feels undesirable.

While this issue is originally about one specific request, it applies more broadly -- there are plenty of other messages we have that can be Bech32-encoded.