Should there be support for base64 encoded binary header values in Metadata?

In [Grpc.Core.Metadata.Entry](https://github.com/grpc/grpc-dotnet/blob/master/src/Grpc.Core.Api/Metadata.cs#L285) there are two constructors for creating metadata entries. One for string values and one for binary values. These constructors validate that the entry key either has or does not have a `-bin` suffix, depending on the used constructor. In practice these constructors are sometimes used to parse HTTP headers into metadata, e.g. [here](https://github.com/googleapis/gax-dotnet/blob/main/Google.Api.Gax.Grpc/Rest/ReadHttpResponseMessage.cs#L69). I encountered a situation interacting with a Google Speech-to-Text API where headers with a `-bin` suffix are included in a HTTP response, but their values are Base64 encoded strings (of byte arrays). This causes exceptions to be thrown when creating Metadata from these responses, as string valued headers cannot have a `-bin` suffix.

I believe encoding binary headers to Base64 is a [common practice](https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md?plain=1#L68) and therefore wonder if such cases should be parsed correctly when creating Metadata entries? Or is it the responsibility of whoever decides to create the Metadata object that all headers have valid combinations of key value types?

Start with src/Grpc.Core.Api/Metadata.cs around the Entry constructors and review the linked HTTP/2 protocol guidance on binary headers. Compare that behavior with the Google.Api.Gax.Grpc response parsing example. Done means reaching a clear decision about whether base64-encoded -bin values belong in Metadata parsing and documenting the expected responsibility.

Written by the indexing model from the issue text.