Permit to pass SslParameters to ExporterBuilders for fine grain TLS configuration

Problem

Post quantum resistant key exchange for TLS RFC is quite stable, enough for Java to implement it in JDK 27.
So when running the JDK OpenTelemetry exporter on java 27, it'll use a post-quantum-resistant algorithm as primary choice (X25519MLKEM768), and this can be defined at the entire JVM level with jdk.tls.namedGroups property.

The issue arise when we want to enforce OTLP to use only PQ-resistant algorithm (by setting jdk.tls.namedGroups=X25519MLKEM768 for example) while needing to call external services that does not offer yet a PQ-resistant key exchange algorithm.
Since the property affects the whole JVM other HttpClients will be impacted.

Proposed solution

Since HttpClient builder accepts javax.net.ssl.SSLParameters, I'd like to be able to pass an instance of these parameters alongside the SslContext in xxxExporterBuilder (such as OtlpHttpLogRecordExporterBuilder).
This way we could easily low level parameters of future TLS handshakes.

Alternatives/Workaround

Since one can currently pass an SslContext, it's possible to create a custom SslContext that will set SslParameters to the SslEngines it produces. But that's about 150 lines of boilerplate code...

Additional context

PostQuantum resistance is a hot topic right now, lots of countries have set deadlines for critical software to become PQ-resistant.

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

Start with the exporter builder APIs, including OtlpHttpLogRecordExporterBuilder, and inspect how SslContext is currently passed to the HTTP client. Review Java's javax.net.ssl.SSLParameters documentation and the existing exporter tests before deciding where the parameters belong. Done means callers can provide SSLParameters alongside SslContext and exporter TLS behavior is covered by tests.