reworked key combiner to be NIST conforming

[falko-strenzke]

This PR brings the following changes:

• Revert the key combiner KDF back to KMAC256. Reason: This is currently the only known way to combine two keys in a NIST-compliant way without modifying the ECC-KEM. See #132 and issue 10 of the NIST/Brainpool draft for details.
• This change also implictly fixes the input-order-problem of the key combiner raised in #127.
• It also implicitly fixes a potential problem regarding the KDF input string being uniquely parsable from the rear raised in #127.
• We remove the counter from the KDF. This is justified by
  • https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf#page=178 which explicitly addresses the general counter removal for KDFs that use only a single iteration
  • and specificly for KMAC as a KDF in NIST.SP.800-108r1-upd1.
• We remove the fixedInfo field and directly replace it with algID. This is merely an editorial change.

Fixes #132. Fixes #127.

Once this is approved we will apply the same construction in https://github.com/openpgp-pqc/draft-ehlen-openpgp-nist-bp-comp.

In the meeting on 2024-08-22, we agreed to create new test vectors only before the publication.

Open work items

Before we can remove the draft status, there is one thing that needs checking regarding the test vectors:

• [x] @wussler @TJ-91 Please check the naming of the key share intermediate values. There was a label "SHA3-256" that I couldn't make any sense of and which I removed. I also added "input to multiKeyCombine" as I assume this is was is meant here. There are still "(??)" marks in the text for this reason which we should remove before merging when my changes have been verified by you.

[falko-strenzke]

You also replaced SHA3 here:

hex-encoded KMAC256 output is TODO.

I think it is more consistent to then also write multiKeyCombine.

Changed it now also to multiKeyCombine.