x-wing: add deterministic encapsulation

[rozbb]

Deterministic encapsulation is super helpful for known-answer tests. I'm currently extending hpke to support X-Wing, and I need to be able to do deterministic encapsulation in order to check against the HPKE test vectors.

The randomness representation is the least controversial in my opinion. Rather than make it a 32-byte seed that gets expanded in some bespoke way, we make it 64 bytes. Thus, this API just exposes a passthrough to the underlying deterministic encapsulation methods. This happens to be how the hybrid KEM draft does this. If this changes in the future, that's fine, because this representation gives the caller full control.

Next steps

I think it'd be nice to move the EncapsulateDeterministic trait into traits/kem. Specifically I was thinking something like

pub trait EncapsulateDeterministic<EK, SS> {
    type Error: Debug;
    type RandomnessSize: ArraySize;

    fn encapsulate_deterministic(&self, randomness: &Array<u8, Self::RandomnessSize> -> Result<(EK, SS), Self::Error>;
}

[rozbb]

Can't replicate the clippy error locally when running cargo clippy --all-features --all-targets -- -D warnings. Not sure what's happening

[rozbb]

I'm just gonna remove the gate actually. This won't stay in this form for that long, since the trait will be upstreamed

[rozbb]

I've changed my mind on the trait. I think it's probably not necessary if it's just useful for testing purposes. No need to make a testing trait public imo. I'm happy to leave things as-is

[tarcieri]

FWIW: https://docs.rs/ml-kem/0.2.1/ml_kem/trait.EncapsulateDeterministic.html (you're probably already using it)

I would like to get rid of all of the bespoke traits in these crates though

[rozbb]

I removed the EncapsulateDeterministic trait from ML-KEM. I now expose encapsulate_deterministic in ML-KEM and X-Wing under the hazmat feature (I also added feature docs to the READMEs).

Ready for review @tarcieri