Add SLH-DSA post-quantum signatures to _CryptoExtras

[fpseverino]

Add support for SLH-DSA post-quantum digital signatures inside _CryptoExtras.

Checklist

• I've run tests to see all new and existing tests pass
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary

If you've made changes to gyb files

• 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" 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 SLH-DSA (AKA SPHINCS+), a stateless hash-based signature scheme standardized by NIST in FIPS 205, that is available inside BoringSSL.

By including SLH-DSA 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 a SLHDSA enum inside the _CryptoExtras module with corresponding PrivateKey, PublicKey and Signature structs that use BoringSSL methods to produce and verify SLH-DSA-SHA2-128s digital signatures, with the code style of other signature schemes in the library.

Result:

SLH-DSA-SHA2-128s digital signatures can be created and verified with Swift Crypto.

[Lukasa]

Thank you for this @fpseverino! I haven't forgotten it: I just want to make sure we get the ML-DSA stuff landed first, to maximise my useful review bandwidth. Is that ok?

[fpseverino]

Absolutely, no problem! I guess you'll recommend avoiding DER/PEM parsing here for now too, if so what should I do with the code I added? Remove it for now or leave it?

[Lukasa]

Yeah, for DER/PEM until we have a standard with final IANA codepoints it's not a good idea for us to add the code unless someone has a need. Easiest thing to do might be to remove it for now, and open a separate draft PR that adds it back?