Consider Into<dyn TokenCredential> instead of Arc<> for creating clients

[heaths]

Guarding access to TokenCredential in its entirety seems overkill. Credentials really only need to guard against multiple writes, which should be rare and, in many cases, inconsequential if there are multiple writers (just wasted time getting multiple tokens e.g., bearer tokens).

Instead of guarding access to the entire TokenCredential, should we just require an Rc<dyn TokenCredential> instead?

[demoray]

Arc is a thread safe Rc. This is important in the case of threaded async runtimes.

The underlying token cache is stored in a RwLock, so in most cases, the impact should be negligible.

[heaths]

Changing the title a bit after the meeting @demoray, @cataggar, and I had today. I appreciate now why we pass an Arc<T> - because it implements Send needed for tokio - but I'm wondering, because it complicates (makes much more verbose) samples, whether we could have clients accept an Into<dyn TokenCredential> since Arc<T> has a blanket implementation of Into<T> that is more versatile. Clients could then wrap it themselves in an Arc<T>.