Add ML-DSA / FIPS 204 final

[bhess]

Adds ML-DSA from FIPS204

Pulls ML-DSA from pq-crystals/dilithium upstream: https://github.com/pq-crystals/dilithium
Removes ML-DSA-ipd alias in favor of ML-DSA.

TODOs:

• Awaiting internal API upstream to be able to run NIST ACVP tests: Question about any differences from PQC standard final version pq-crystals/dilithium#88 (comment)
• NIST ACVP vectors against the external API (that will be exposed to the user), expected by October: ML-DSA: integrate final standard #1891 (comment) Postponed for ACVP availability
• Pre-hash variants / Algorithm 4/5 in FIPS 204 Postponed for ACVP availability
• oqs-provider "-tracker" branch
• add API to be able to pass 'ctx' string
• update constant-time tests

FIPS 204 further defines a context parameter 'ctx' passed to the sign/verify API. This is currently not supported with the OQS API. It also defines

By default, the context is the empty string, though applications may specify the use of a non-empty context string.

This PR makes only this default case available. Asking for feedback if we should adapt/add to the OQS Sign API to accomodate such a 'ctx' string, or if we restrict support to the default case.

• Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged.)

Closes #1891

[dstebila]

The remaining tasks have been implemented, and the oqs-provider downstream tests are passing. The new APIs are so far named OQS_SIG_sign_with_ctx_str and OQS_SIG_verify_with_ctx_str. An alternative could be OQS_SIG_sign_with_context or OQS_SIG_sign_with_context_string. Is there a preference?

I avoided OQS_SIG_sign_with_context because the term "context" alone is somewhat overloaded and might be misinterpreted as referring to a state structure. While OQS_SIG_sign_with_context_string is more verbose, it seems to align better with the typical naming in liboqs.

Makes sense to explicitly say context string rather than just context. I don't have a preference between ctx_str and context_string.

[SWilson4]

Everything LGTM now. Thanks to @bhess for the work and to all for the effort in discussing the API changes!

[bhess]

Thanks @SWilson4 for going through all the changes and for the review!

[dstebila]

Is this ready to merge?

[bhess]

Yes, this is ready to merge from my side. I will proceed with the merge in about an hour unless there are any objections.