feat: implement OAuth 2.0 Client Credentials flow

[DaleSeo]

Fixes #522

Motivation and Context

MCP's authorization model currently needs users to authorize through the standard OAuth 2.0 authorization code flow. This works great for scenarios where a person is involved, but it doesn't cover many machine-to-machine use cases, like CI/CD pipelines, backend services, and automated agents, where there's no user available to approve a browser-based consent screen.

SEP-1046 addresses this issue by adding the OAuth 2.0 Client Credentials grant (RFC 6749 Section 4.4) as an optional extension to MCP authorization. This PR implements that specification in the Rust SDK, offering two authentication methods: client_secret for simple shared-secret setups and private_key_jwt (RFC 7523) for asymmetric key-based authentication, which avoids sending secrets over the wire.

The implementation fully relies on the existing auth module infrastructure. Metadata discovery, credential storage, token refresh, AuthClient, and AuthorizedHttpClient all function as they did before. The new code just adds an alternative way to get the initial access token without needing interactive authorization.

How Has This Been Tested?

Along with the unit tests, there's an integration test that sets up a mock OAuth server using axum. This server provides the standard well-known metadata endpoints and a token endpoint. We cover three scenarios: a successful client_secret exchange that verifies the returned token, a request with an invalid secret that checks for an error, and a request with an unknown client ID that also confirms failure.

Breaking Changes

None. This is a purely additive change. All new types and methods are behind the existing auth feature flag.

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