Add client_secret_basic and none authentication methods

[SightStudio]

Add support for client_secret_basic and none OAuth client authentication methods to complement the existing client_secret_post method.

Motivation and Context

Currently, the TypeScript SDK only supports client_secret_post authentication method for OAuth token exchanges. However, OAuth 2.1 specification defines multiple client authentication methods, and many authorization servers prefer or require client_secret_basic (HTTP Basic authentication) for better security practices.

This change adds built-in support for:

• client_secret_basic: HTTP Basic authentication (RFC 6749 Section 2.3.1)
• none: Public client authentication (RFC 6749 Section 2.1)

The implementation automatically selects the best authentication method based on server capabilities and client credentials, following OAuth 2.1 best practices.

How Has This Been Tested?

• All existing tests continue to pass (403 tests)
• Added 6 new comprehensive test cases covering:
  • client_secret_basic authentication in both exchangeAuthorization and refreshAuthorization
  • client_secret_post authentication (existing behavior)
  • none authentication for public clients
  • Automatic method selection based on server metadata
  • Fallback behavior when server metadata is unavailable

Breaking Changes

No breaking changes. This is fully backward compatible:

• Existing code using client_secret_post continues to work unchanged
• New authentication methods are automatically selected when appropriate
• All existing APIs maintain the same signatures

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

Design Philosophy: Built-in vs External Implementation

This PR takes a different approach from PR #531, which delegates authentication to external providers via an authToTokenEndpoint callback.

While that approach offers maximum flexibility,
But I believe that standard OAuth authentication methods should be built into the SDK for the following reasons:

1. Simplicity: Standard methods like client_secret_basic and none are well-defined in RFC 6749 and don't require custom implementation
2. Reduced Complexity: Users don't need to implement standard authentication methods themselves
3. Consistency: All OAuth 2.1 implementations should handle these basic methods uniformly

The external delegation approach in PR #531 is better suited for advanced/custom authentication methods like private_key_jwt that require specialized cryptographic operations and key management.

[SightStudio]

Please consider this request positively, as our internal OAuth provider only supports
client_secret_basic (I know that’s not ideal, but that’s the situation on our side),

So this feature is truly essential for us.

[SightStudio]

has simillar issue in python sdk
modelcontextprotocol/python-sdk#778