Demonstrate build with all 3 parameter sets in CI

[rod-chapman]

Consumers of mlkem-native (e.g. other major cryptographic libraries) will likely want to include all three ML-KEM parameter sets for their users.

We therefore need to demonstrate that mlkem-native can be built 3 times with MLKEM_K=[2,3,4] and the resulting object files combined into a single library with no clashes.

On platforms that support it, this should be demonstrated for producing both a static- and a dynamically-linked library.

[hanno-becker]

I agree.

@mkannwischer @potsrevennil What are your thoughts on changing the build so it generates a libmlkem{512,768,1024}.a in the interim, and we demonstrate in a separate test that all those link together into libmlkem.a?

[rod-chapman]

I like that idea. Some consumers might want just one (small) library that implements just 1 parameter set. Some consumers might want all 3. We need to demonstrate that both options are possible and easy.

[rod-chapman]

Do we currently have a clear distinction between functions and/or translation units that depens on MLKEM_K and those that don't? For example, reduce.[hc] do not depend on MLKEM_K and so really shouldn't be compiled 3 times and produce 3 copies of the same code (albeit with different naming prefixes). Same for ntt.[hc] - that code is common to all parameter sets, right, so could be compiled exactly once?

[hanno-becker]

No, they are all namespaced. Doing things without duplication would be out of scope initially.