refactor: remove deprecated OAuth authentication base classes

[Romazes]

Description

Remove deprecated OAuth authentication base classes superseded by the concrete
implementations introduced in #9330. Cleans up Brokerages/Authentication/ by deleting:

• OAuthTokenHandler.cs — generic OAuthTokenHandler<TRequest, TResponse>, replaced by LeanOAuthTokenHandler
• TokenHandler.cs — abstract TokenHandler<T>, replaced by LeanTokenHandler
• TokenCredentials.cs — replaced by LeanTokenCredentials
• AccessTokenMetaDataRequest.cs — abstract base, replaced by OAuthTokenRequest
• AccessTokenMetaDataResponse.cs — abstract base no longer needed; expiry tracking moved into the handler

Also updates XML documentation in LeanOAuthTokenHandler.cs and LeanTokenHandler.cs
to reference the new concrete types.

Related PRs

All new OAuth logic was implemented in PRs:

• https://github.com/QuantConnect/Lean.Brokerages.CharlesSchwab/pull/81
• fix: enforce explicit OAuth token lifetime, set Tastytrade to 15 minutes Lean.Brokerages.Tastytrade#21

Related Issue

Follows up on #9330 — feat: add CreateOAuthTokenHandler factory to Brokerage base class

Motivation and Context

PR #9330 introduced the new concrete, non-generic authentication handlers as part of the
OAuth authentication failure shutdown feature. The old abstract/generic base classes
(OAuthTokenHandler<TRequest, TResponse>, TokenHandler<T>, etc.) became dead code
and are removed here to keep the codebase clean.

Requires Documentation Change

No. The removed classes were internal infrastructure not referenced in public documentation.

How Has This Been Tested?

Verified the solution builds successfully after deletion. All callers of the deleted
classes were already migrated to the new concrete types in #9330.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>