[Feature]: Split Option types for Handler and Transport in otelhttp

[NesterovYehor]

Component

Instrumentation: otelhttp

Problem Statement

Addressing the v1.0 stabilization audit #8107.
Currently, NewHandler and NewTransport share the same Option type and internal config struct. This allows users to accidentally pass Transport-specific options (like WithClientTrace) into a server Handler without compiler errors, leading to silent runtime failures and weakened API boundaries.

Proposed Solution

1. Split internal state: Divide the shared config into handlerConfig and transportConfig.
2. Define specific interfaces: Introduce HandlerOption and TransportOption with their respective apply methods.
3. Define a shared interface: type Option interface { HandlerOption; TransportOption } for common options (e.g., WithPropagators).
4. Update constructors: * func NewHandler(..., opts ...HandlerOption)
5. func NewTransport(..., opts ...TransportOption)
6. Options will be updated to return their most restrictive interface.

Alternatives

No response

Prior Art

No response

Additional Context

Breaking Change: Changing the constructor signatures is a breaking API change for users mixing option types, but it is necessary to achieve type safety before the v1.0 freeze.

[NesterovYehor]

I am ready to open a PR for this if the architectural direction is approved.

[pellared]

@dmathieu, PTAL as code owner of otelhttp

[dmathieu]

I agree, this change makes sense to me.