Implement support for client_credentials

[LucaButBoring]

Implements support for the client_credentials flow over client_secret_basic/client_secret_post. Requires the client to explicitly declare support for the client_credentials grant type, as demonstrated in the example code.

Motivation and Context

Enables machine-to-machine auth and using IdPs that don't support a code grant flow.

How Has This Been Tested?

Added an example that integrates with Discord using this flow. The example does not use Dynamic Client Registration because the OAuthProvider boilerplate that offers that has the authorization code grant flow baked into it right now. Instead, a dummy client ID and client secret are hardcoded in the TokenStorage implementation.

Breaking Changes

• Possible breaking change? OAuthClientInformationFull.client_id is now optional as described in the OAuth 2.1 specification, section 3.2.2.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

#709

[SoldierSacha]

I also implemented this, along with the token exchange grant type in addition to client credentials

#882

[LucaButBoring]

@pcarleton @dsp-ant Let me know if I should close this in favor of #882, or if the credential grants should be PR'd separately (whether that looks like #882 being split or scoped down to token_exchange). There is also now an SEP that would benefit from either PR to satisfy the implementation example requirement.