Support Pre-Hash and Context in ML-DSA/SLH-DSA

[reneme]

The final standards for ML-DSA and SLH-DSA support a pre-hash mode and allow applications to specify a short "context" string. Both of those features won't be available in Botan 3.6.0. They depend on the more flexible API that is being discussed in #4318 and will be implemented in a future release.

[atreiber94]

We decided to not implement the HashML-DSA and HashSLH-DSA variants for now.

FIPS204 allows a FIPS204 key to be used for either variant ( ML-DSA or HashML-DSA) but recommends against it [FIPS204, Section 5.4]. Whether to use pre-hashing or not and which hash function to use is only relevant for signing/verifiying and is specified by the signature identifier [FIPS204, Section 5.4].

We thus could either add

1. A PreHash Option for the Signer/Verifier (ignoring the NIST recommendation) or
2. A PreHash Option for the Key (forcing the NIST recommendation) or
3. A combination of Options 1 and 2 where the Signing/Verifier options overwrite the Key Option (using NIST recommendation as default but explicitly wanting to violate it is ok).

The issue is that while FIPS204 only requires the signature identifier to specify the variant and hash algo, the OIDs for ML-DSA keys enforce the recommendation to restrict keys to one variant and only specify ML-DSA and HashML-DSA with SHA512.

So Option 1 would clash with the semantics of the existing OIDs as an application or its counterpart would assume that the OIDs strictly denote the variant. If, e.g., a key's OID needs to be written to a certificate, with this option it is not clear which variant OID to pick.

Option 2 would be in line with the OID semantics but would disallow any applications that would want to not follow the recommendation for whatever reason (which is still compliant to FIPS204) - or at least force it to dance around the API and re-load the key bytes with another OID etc.

Option 3 gives the most flexibility but we are not sure if such flexiblity is required. Pure ML-DSA is the preferred algorithm and HashML-DSA is designed for systems where one module performs the hashing and another module the signing. Botan does not seem like such a system and hence should only be compatible to such systems.

There seems to be some confusion of how to handle this case. BouncyCastle seems to use Option 2, the reference implementation and liboqs only use the pure variant, but wolfSSL seems to break the spec API and allows to pass the hash of the message as input and not the message itself.

Hence, for all these reasons we feel like this functionality can be added later on after it is clear which kind of demand for it exists. The reasoning is the same for FIPS205/SLH-DSA.