Update ML-KEM for compatibility with OpenSSL 3.5 implementation

[mamckee]

This PR updates the SymCrypt provider ML-KEM and ML-KEM hybrid to match the behavior of the OpenSSL default provider implementation, added in OpenSSL 3.5. This PR also fixes minor bugs and behavior differences found when testing the SymCrypt provider with OpenSSL 3.5's new ML-KEM tests.

• Different ML-KEM parameter sets, and hybrid algorithms are now registered as their own algorithm for key management, KEM, encode, and decode.
• Split ML-KEM hybrid into its own key management and KEM interfaces to better match OpenSSL's behavior and for maintainability.
• Removed ML-KEM hybrid encoder and decoders since they don't exist in OpenSSL 3.5 and are based on test OIDS.

[samuel-lee-msft]

Would be good to be clear wherever you're doing the hybrid code that these names and algorithms are correct only in the context of TLS key exchange.

There are different combiners for use in CMS / HPKE, known as:
"Composite-ML-KEM"
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/
and "Hybrid PQ/T KEM":
https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/blob/main/draft-irtf-cfrg-concrete-hybrid-kems.md#concrete-hybrid-kem-instances

Which are compatible with each other, and use the same component algorithms, but use SHA3-256 with the shared secret outputs + a label to produce a 32-byte shared secret, rather than directly outputting concatenated shared secret.

[mamckee]

I need to dig deeper into how these algorithms are exposed for CMS through OpenSSL and see if there's a way to only expose these for TLS then as well.

[qmuntal]

FYI We recently added support for MLKEM to https://github.com/golang-fips/openssl, so you can use it to test that you will be at least compatible with the Microsoft build of Go.