Introduce IntoDynChannelCredentials trait for flexible channel creds.

[nathanielford]

To support creating channels with various credentials configurations, we need to accept different credential representations (such as concrete types or Arc-wrapped trait objects). This trait provides a common conversion interface to type-erase these representations internally. This refactoring is isolated to its own commit to keep subsequent feature commits focused and legible.

Motivation

When working on the Channel builder, it became clear having into traits for DynChannelCredentials would be useful. Because this trait is private, being able to automatically convert public implementors of the ChannelCredentials trait to what we are using internally was the ergonomic option.

Solution

Add the into traits, update the relevant public traits to support it.

[dfawley]

I'm not sure I understand exactly why this change is needed. I think we want to convert into the Dyn version of the trait internally, and not expose that trait to anyone else.

We already have the blanket impl of DynChannelCredentials -- why isn't that good enough? Is it because the blanket impl specifies T::Output more narrowly than the channel builder does?

[nathanielford]

@arjan-bal I'm looking into other ways of achieving this, per Doug's comment about this maybe not being necessary, but you can look at what I'm attempting with the channel type builder here: master...nathanielford:grpc-rust-nford:implement/channel-builder

As soon as that's stable I'll create it's own PR for it, which currently relies on this PR, but if we decide we don't need it I can excise this chunk easily.

[arjan-bal]

@nathanielford, I was looking at ChannelBuilder::credentials in #2675, but I'm having trouble understanding the need for the new IntoDynChannelCredentials trait. Could you clarify what issue prevents us from using the same input parameter as the current channel constructor (i.e., Arc<C> where C: ChannelCredentials, C::Output<Box<dyn GrpcEndpoint>>: GrpcEndpoint + 'static)?

---

For context, the constructor accepts an Arc<C> because the credentials passed during channel creation might be reused to create "out of band" (OOB) channels (e.g., to an RLS server). If we don't require the Arc in the input type and instead wrap the credentials inside the constructor, creating an OOB channel would result in wrapping them in an Arc a second time. This would lead to redundant pointer indirection and reference counting.

An alternative approach I considered was defining a wrapper struct:

pub struct SharedChannelCreds {
    inner: Arc<dyn DynChannelCredentials>,
}

The channel constructor would then accept impl Into<SharedChannelCreds>. We would provide a blanket impl<C: ChannelCredentials> From<C> for SharedChannelCreds and also implement ChannelCredentials for the wrapper itself.

This prevents double Arcing as a SharedChannelCreds object could be passed directly to the OOB channel, and calling .into() on it would simply return the object itself. However, we decided against this approach because it obscures the underlying API. Once the credentials APIs are unsealed, hiding the requirements behind Into<SharedChannelCreds> would make it harder for users to discover exactly which trait they need to implement for custom credentials.