Add Azure AD token provider

[simoleone]

The main goal of this change is to provide a way to get dynamic auth tokens into the client. The most common use-case for this is with Azure, when the token may be for a federated identity obtained using OIDC, which needs to be refreshed periodically. Another use-case for it is development scenarios against Azure when you're authenticated as yourself instead of using the static access token for the REST endpoint. In that case you might dynamically obtain/refresh a valid auth token by shelling out to az account get-access-token.

Because these kinds of tokens have relatively short expirations, they need to be refreshed, so we accept any proc-like object and call it upon every http call to get the current token. Implementors can cache this if they wish.

I also moved some configuration validation into the client. Because the client merges key-by-key, we have to ensure we re-validate it after this merge has occurred.

I made a small change to the way configuration is merged. Previously, passing a nil value would have the same behavior as not passing a key at all, which is problematic if you explicitly want to set a certain key from the global config to nil. Now, all provided keys are set, including nil.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you added an explanation of what your changes do and why you'd like us to include them?

[deepracercve]

It'd be great to include this. Given some policy limitations on our side - a token provider might be the only way to go.

[simoleone]

Hey @alexrudall ! Is there anything I can do to help move this forward?

[deepracercve]

I second @simoleone and would like to see if there's any support needed to have this included.

[alexrudall]

Hi @simoleone @deepracercve, thanks for this PR & for your patience! I'm considering releasing a 'pro' version of ruby-openai that would allow me to prioritise testing & merging features like this before adding to the free version at a later date - similar to sidekiq-pro & graphql-pro. I would also offer ongoing support, and other improvements including performance enhancement. Would your use cases justify this? Likely cost $299/year or similar. Again, thank you for your patience.

[deepracercve]

I can't tell you how you'd support your efforts. However, I think it's a chicken-egg situation; the more we can provide capabilities to Ruby, the more appetite there is within my env to support a paid-model.
I don't think we'd be able to justify a license without proving capabilities.