Add SSL_client_hello_get0_extensions() raw accessor

SSL_client_hello_get0_session_id(), get0_random(), get0_ciphers(), and get0_compression_methods() each provide zero-copy access to the corresponding ClientHello field. No equivalent exists for extensions.

The existing extension APIs have documented limitations:

• SSL_client_hello_get0_ext() requires knowing the type ID upfront
• SSL_client_hello_get1_extensions_present() only returns extensions recognized by ext_defs[], omitting GREASE values and types not built into the library

The documentation for SSL_client_hello_get1_extensions_present() explicitly notes this limitation:

Note that SSL_client_hello_get1_extensions_present() returns only recognised extensions; therefore, unrecognised (including GREASE) extensions will not appear in the output.

This creates an inconsistency: SSL_client_hello_get0_ciphers() returns raw cipher bytes including GREASE values, but there is no equivalent for extensions.

Related issues: #18286 (get1_extensions_present missing extensions), #27580 (GREASE inconsistency between ciphers and extensions).

Proposal

Add SSL_client_hello_get0_extensions() following the same pattern as get0_ciphers() -- return a pointer into the PACKET buffer and the byte count. The pointer is valid for the duration of the client_hello_cb.

size_t SSL_client_hello_get0_extensions(SSL *s, const unsigned char **out);

This gives callers complete visibility into the extensions present on the wire, including GREASE and types unknown to the current OpenSSL version, useful for protocol analysis, logging, and server-side policy decisions. The returned data uses the standard TLS extension wire format (type/length/data entries), without the 2-byte total length prefix.

I have a working implementation with tests and documentation ready to submit as a PR if this approach is acceptable.