Add dedicated ClientOptions types for each client

[joseharriaga]

Summary

Most clients currently use OpenAIClientOptions directly in constructors and ClientSettings. We should introduce a dedicated *ClientOptions type for each client, following the existing ResponsesClient / ResponsesClientOptions pattern.

Motivation

Using a shared OpenAIClientOptions across most clients makes the API less consistent and gives each client no clear place for client-specific configuration. We already have a better pattern in ResponsesClient, and the rest of the library should align with it.

Requirements

• Add a dedicated *ClientOptions type for each client.
• For Experimental clients, replace constructor and settings dependencies on OpenAIClientOptions with the dedicated type.
• For non-Experimental clients that are already GA, keep existing OpenAIClientOptions support side-by-side with the new dedicated type to avoid breaking stable APIs.

Scope

This should include:

• public constructors
• ClientSettings.Options
• configuration binding paths
• any other dependencies that currently tie a client to OpenAIClientOptions

Acceptance criteria

• Every client has a dedicated *ClientOptions type.
• Experimental clients no longer depend on OpenAIClientOptions as their client-specific options type.
• Stable clients keep existing OpenAIClientOptions entry points for compatibility while also supporting the new dedicated options type.
• API shape is consistent with the ResponsesClient pattern.