Prepare to detect side-channels in compiled ML-KEM code

Prepare to detect side-channels in compiled ML-KEM code

Loosely based on similar code in BoringSSL.

Added the valgrind macros necessary to mark secret inputs as uninitialised on
entry to the ML-KEM keygen, encap and decap functions.  The inputs and outputs
are then untagged before control returns to the caller, where, at least in the
case of tests and protocols that check whether the derived keys succeeded in
decoding a key-confirmation message, there will at some point be a branch based
on the *content* of the compute shared secret.

When a build is configured with `-DOPENSSL_CONSTANT_TIME_VALIDATION`, and
various tests that use ML-KEM are run under:

    $ valgrind --tool=memcheck --error-exitcode=1 --exit-on-first-error=yes cmd [args]

any internal secret-data-dependent branches added by a mis-optimising
compiler, or inadvertently introduced into the source code would cause
the tests to fail, exposing the side channel.

Since the side-channels are liable to depend on the compiler and
selected optimisation flags, tests would need to cover a few combinations.

    * clang vs. gcc
    * debug builds
    * default builds
    * -O2
    * -O3 -fno-vectorise (a problem with clang in "clangover")
    * -Os (was a problem with clang in "clangover")
    ...

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26270)