Play Framework

perf(ssl): prefer BoringSSL provider for Netty TLS (PF-105)

Netty's JDK-SSLEngine path was the only TLS provider in play; OpenSSL/
BoringSSL handshakes are 2-3x faster and the symmetric path is faster
via native AES-NI than JDK intrinsics. SslHttpServerPipelineFactory now
picks SslProvider.OPENSSL_REFCNT when OpenSsl.isAvailable() reports true
and logs one boot-time info line with the selected provider + version;
the JDK provider remains as a warn-logged fallback so a missing native
classifier surfaces explicitly. OPENSSL_REFCNT (not OPENSSL) because the
SslContext is cached for the JVM lifetime via the existing volatile DCL
in buildSslHandler, which the refcounted variant is built for.

dependencies.yml grows netty-tcnative-classes (Java API peer required
by OpenSsl static-init under transitiveDependencies: false) and the
five platform-classifier jars for netty-tcnative-boringssl-static
2.0.71.Final, matching the per-classifier shape already used for
netty-codec-native-quic. macOS aarch64 integration test confirms
"TLS provider: OpenSSL/BoringSSL (BoringSSL, ALPN=true)" at boot.