Add support for hybrid forward secrecy (hfs) modifier

[jchambers]

This takes a crack at implementing the hybrid forward secrecy (hfs) modifier as described in the draft Noise HFS specification as of 025f0f60.

This whole thing is built on a slightly shaky foundation in that the HFS modifier specification is still very much a draft and leaves some important details (what are the acceptable cipher suites? what are their names? how does this interact with the fallback modifier?) up for discussion. I've done my best to make reasonable decisions on my own, but recognize that reasonable minds may disagree with some of them.

The Java ecosystem still doesn't—yet!—have well-established patterns for KEMs yet. I think the interpretation provided in kyberJCE makes sense, but recognize it may change as KEMs (and post-quantum cryptography more broadly) gain better adoption in the JDK. I also couldn't find a straightforward ML-KEM implementation, and so stuck with Kyber for now.

There's a lot to discuss and iterate on in here, and also a lot of more straightforward TODOs (e.g. write docs) to address, but I think this gives a pretty good idea of what things might look like if this were to make its way into main.

This closes #1.

TODO:

• Identify a credible source of test vectors
• Codify KEM algorithm names
• Find a solid ML-KEM implementation(?)
• Polish documentation
• Resolve issue where NoiseHandshakeBuilder#setComponentsFromProtocolName can't handle handshake modifiers (an existing issue!)
• Resolve interactions between hfs and fallback modifiers
• Align naming/terminology with FIPS 203

[jchambers]

Java 24 introduces support for ML-KEM, so I'm going to rework things a bit here to embrace that.

[jchambers]

I've reworked this to use the KEM interface introduced in Java 21. Java 24 packages aren't widely available yet (including GitHub Actions runners), so I'll hold off a little before diving into the ML-KEM bits. For now, I added a concrete implementation with DHKEM, mostly as a proof-of-concept.