Bring sampling and cryptographic functions in ML-KEM up to gold standard

[marsella]

This is a bunch of small clean-up tasks that arose during implementation of #143. They're all related to pseudo-randomness and sampling. See ML-KEM spec, gold standards

I also think that there is some un-aligned bit ordering in here that's caused by SHA3. The SHA-3 spec expects bits in an unusual order (MSB bytes, LSB bits) for both input and output; previously, the SHA-3 interface required the user to pass / take their input / output in that order. As of #142, there is a sleeker SHA-3 interface that interacts with MSB bit vectors. However, ML-KEM assumes bit vectors are in LSB order. There is some strange usage of SHA3 in ML-KEM: the uses of SHAKe128 and SHAKE256 convert from MSB to SHA3 bit vectors, but returns SHA3 bit vectors. ~I'm not sure whether there are additional bit order changes in some of the other bit-manipulation functions, like BytesToBits, BitsToBytes, and maybe the BitstoZ and ZtoBits~ (see comment for notes on these conversions). The gold-standard version of this spec should use the gold-standard version of SHA-3, so we will need to track down all the places where bit ordering is compensating for SHA-3 and remove them from this spec.

• [x] Replace the parameterized import of SHA3 with concrete imports of SHA3-256 and SHA3-128
• [x] Update uses of SHA3 (hash and xofs) to use the new API that doesn't require reversing bits (related: #138, #142)
  • [x] Fix any other bit ordering functions that propagate this issue.
• [x] PRF: Tighten the constraint on the eta parameter (should only be 2 or 3). Make sure it aligns with the spec (byte count, not bit count). Maybe just call it eta.
• [x] SampleNTT: make inf version a function in the where instead of a standalone thing. Try to simplify the control flow to look more like the spec. Explain where laziness trumps spec-matching (e.g. there is no j.)
• [x] SamplePolyCBD: Tighten bound on eta. Update naming & details to look more like the spec. Adjust spacing to be more consistent with Marcella's preferred standards 🙃 (someday perhaps soon I'll write a style guide).

[marsella]

In our implementation, the hash functions XOF and J and PRF all use SHAKE functions and call toBytes on the input but use the output as-is. The manual transformation of the bytes to put them in the correct order happens elsewhere:

• XOF: this gets passed to SampleNTT, and there are extra reverses on the bytes in there

• PRF: this manually does the reversal itself

• J: this is only used to "implicitly reject" a badly-formed decaps request, which we don't test right now -- so, it's probably a bug in the current version. Also note that we need to add some warnings around this behavior -- they're in Section 6.3.

• [x] Add a test to check if we got J right.