Add AzurePipelinesCredential

[heaths]

Resolves #2030. This includes some small amount of refactoring of existing code that will be necessary sooner than later, but I didn't want to take all that on in this PR focused on AzurePipelinesCredential. Still, I wasn't about to repeat the same antiquated patterns.

[heaths]

There are some TODOs that require some heavy lifting, like using either the azure_core Pipeline or making an azure_identity-specific one; however, I want to focus on an MVP that enables our live tests since we need to get those up and running ASAP (/cc @hallipr). azure_identity needs a lot of work already including some major refactoring, using more of the pipelining, etc., so we can do all that then and be consistent.

@RickWinter @JeffreyRichter @analogrelay as we start getting more and more nested options, the API is feeling a bit unwieldy. In addition, I'm not crazy about making it obvious we use a ClientAssertionCredential by nesting it's options. It's not that I think we should hide it, but feels like shipping an implementation detail (just like we shouldn't ship our org chart). Guidelines do leave the possibility of builders open, so should we consider that for credentials? Or do we duplicate fields and manage all that as we make changes? It's not terribly hard since Rust forces us to assign fields if we don't use ..Default::default().
I'm open to other suggestions on design, too.

[heaths]

@analogrelay any other good ideas here? The DX this forces (see test below; we have to pin the future) is unwieldy but I couldn't figure out a better way without taking advantage of Rust 1.85 async captures.

[heaths]

I cleaned it up a little using a BoxedFuture, though the boxed() "extension method" probably does more heavy lifting here. Still open to other suggestions, but this seems to be a fairly common solution I found - more than what inspired me originally.