AzureCliCredential: add support for expires_on field.

[antkmsft]

Closes #5116.

It works the following way - if expires_on (the new one) property is present, it gets parsed before ExpiresOn (the old one) property.

This PR is not a replacement for #5179, which mitigates the issue if the user has older version of Azure CLI installed. We can't expect users to always have the latest installed. The one without time zone info has been there first, for many years, and only now they are adding the expires_on property.

#5179 is good enough, but not ideal - once a year, one day in fall, when it is close to moving from DST, the token will be off for one hour, and then everything should work, but an extra token request will be sent when the auth policy will supply a token which was obtained when the DST was on, but the service will reject it, and then the policy will tell the credential to get a new token, and everything will work once again.
And one day in spring, when the clock moves to DST, the tokens obtained will have 1 hour shorter expiration than what they actually are, and some extra requests to refresh tokens will be made.

--
UWP CI is currently blocked until microsoft/vcpkg#35279 is fixed / microsoft/vcpkg#35116 is merged (#5181 would unblock)

[ahsonkhan]

Let's wait on this until we have a conclusion on Az Cli version support.

[antkmsft]

Let's wait on this until we have a conclusion on Az Cli version support.

Sure.
When will we know?
BTW, if the decision is to require the newer azure CLI version, I would want to talk to them, because there is no reason to drop the support entirely - we perfectly can parse timestamps in the old format - especially with #5179 we could do that, and it would be excessive in getting tokens twice a year in the locales that move to DST and back.

[ahsonkhan]

When will we know?
BTW, if the decision is to require the newer azure CLI version, I would want to talk to them, because there is no reason to drop the support entirely - we perfectly can parse timestamps in the old format - especially with #5179 we could do that, and it would be excessive in getting tokens twice a year in the locales that move to DST and back.

I discussed this today and shared the conclusion on the issue:
#5116 (comment)

The other languages don't have the DST concern, let's discuss that separately. It does seem like that's an OK trade-off given where C++ language support is, and given AzureCliCredential is a dev time credential anyway.

[ahsonkhan]

Otherwise, LGTM.