Update McEliece suppression files for generic config

[SWilson4]

This PR updates the suppression files for the "clean" (pure C) implementation of Classic McEliece. I've run the tests both in a container built from the CI image and locally on my machine.

For now, I've labelled all of these as "issues", as I'm not knowledgeable enough about McEliece to confidently classify them as false positives or true instances of secret-dependent behaviour. I believe that this is in line with what we had done previously for the AVX2 constant-time failures.

To test:

rm -rf build && mkdir build && cd build
cmake -GNinja -DOQS_DIST_BUILD=OFF -DOQS_OPT_TARGET=generic -DCMAKE_BUILD_TYPE=Debug -DOQS_ENABLE_TEST_CONSTANT_TIME=ON .. && ninja ; cd -
python3 -m pytest -n=auto -k "McEliece" -v tests/test_constant_time.py

Partially addresses #1666.

I suspect that this may also address #1540. @bhess @praveksharma is it plausible that the "env-specific" constant-time errors were simply caused by building without AVX2 optimization? There were previously no suppressions for the "clean" implementation.

• 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 and OQS-OpenSSH will also need to be ready for review and merge by the time this is merged.)

[SWilson4]

I've just updated the weekly constant-time runs so that the smallest parameter set of McEliece is tested there. I don't think it will add too much overhead, and it will (hopefully) make sure that we don't let these suppression files get out of sync in the future.

[baentsch]

LGTM -- assuming McEliece does not make it into the proposed "production ready" setup.