Refactor AccessTokenProvider to relieve some concerns to TokenRequestContext

PhpLeagueAccessTokenProvider mixes two many concerns:

• wrapper between the authentication provider and the auth context (original design)
• validates hosts through the validator (original design)
• CAE support (original design)
• provides observability information (original design)
• token caching (not part of original design)
• token refresh (same)

Because of that, and specialization with national endpoints, to expose the full API surface, we're leaking those concerns to derived classes, or required to add this setter.

And even with the latter approach, their does not seem to be a way for a consumer of the Graph Authentication Provider to set the token cache for the access token provider... Masking some of the customization abilities, or loosing the specialization for national clouds etc in the process.

Beyond the degraded developer experience, we risk introducing "experience bugs" where settings things one way doesn't flow all the way down, but does by using another API.

I believe the correct thing to do would be to move the concerns that should not be in PhPLeagueAccessTokenProvider to the token request context. I understand this is a significant undertaking and would be considered a breaking change.

further context: https://github.com/microsoft/kiota-authentication-phpleague-php/pull/106

Start by reviewing PhpLeagueAccessTokenProvider and TokenRequestContext, then read the further context in pull request #106. Map the listed concerns and how national-endpoint specializations currently use them. Done means the responsibilities are placed in the intended context without losing token-cache, refresh, CAE, validation, observability, or customization capabilities.