Add ML-KEM post-quantum key agreement to _CryptoExtras (apple#314)

Add support for ML-KEM post-quantum key encapsulation mechanism inside
`_CryptoExtras`.

<!-- Thanks for contributing to Swift Crypto! Before you submit your
issue, please make sure you followed our checklist and check the
appropriate boxes by putting an x in the [ ]: [x] -->

### Checklist
- [X] I've run tests to see all new and existing tests pass
- [X] I've followed the code style of the rest of the project
- [X] I've read the [Contribution Guidelines](CONTRIBUTING.md)
- [X] I've updated the documentation if necessary

#### If you've made changes to `gyb` files
- [x] I've run `.script/generate_boilerplate_files_with_gyb` and
included updated generated files in a commit of this pull request

### Motivation:

With the advent of quantum computing, the mathematical foundations on
which the cryptographic protocols in use today are based have been
questioned, as they can easily be circumvented and violated by quantum
computers.

While waiting for the creation of quantum computers that work at full
capacity, and to protect network communications from "[Harvest Now,
Decrypt
Later](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later)"
attacks, the cryptographic community is working on post-quantum
cryptography algorithms, which work on the traditional computers we use
today, but are resistant to future attacks by quantum computers.

One of these algorithms is ML-KEM (AKA Kyber), a module lattice-based
key encapsulation mechanism standardized by NIST in [FIPS
203](https://csrc.nist.gov/pubs/fips/203/final), that is available
inside BoringSSL.

By including ML-KEM inside Swift Crypto, we can get closer to
normalizing quantum secure algorithms and start implementing them into
our apps and libraries to make them quantum-proof.

### Modifications:

Added `MLKEM768` and `MLKEM1024` enums (generated with `gyb`) inside the
`_CryptoExtras` module with corresponding `PrivateKey` and `PublicKey`
structs that use BoringSSL methods to decapsulate and encapsulate
ML-KEM-768 and ML-KEM-1024 ciphertexts, with the code style of other
KEMs in the library (they also conform to `KEMPrivateKey` and
`KEMPublicKey` protocols).

### Result:

ML-KEM key agreements can be handled with Swift Crypto.

Author: fpseverino

Sources/CCryptoBoringSSL/include/CCryptoBoringSSL.h

@@ -45,6 +45,7 @@
 #include "CCryptoBoringSSL_md4.h"
 #include "CCryptoBoringSSL_md5.h"
 #include "CCryptoBoringSSL_mldsa.h"
+#include "CCryptoBoringSSL_mlkem.h"
 #include "CCryptoBoringSSL_obj_mac.h"
 #include "CCryptoBoringSSL_objects.h"
 #include "CCryptoBoringSSL_opensslv.h"

Sources/_CryptoExtras/CMakeLists.txt

@@ -42,6 +42,7 @@ add_library(_CryptoExtras
   "Key Derivation/Scrypt/BoringSSL/Scrypt_boring.swift"
   "Key Derivation/Scrypt/Scrypt.swift"
   "MLDSA/MLDSA65_boring.swift"
+  "MLKEM/MLKEM_boring.swift"
   "OPRFs/OPRF.swift"
   "OPRFs/OPRFClient.swift"
   "OPRFs/OPRFServer.swift"