[afchine1337]

First of the PRs planned in #249.

Mechanism.ML_DSA takes an optional CK_SIGN_ADDITIONAL_CONTEXT in PKCS#11 v3.2: the FIPS 204 context string and the hedging variant. Until now the only way to pass it was a raw bytes parameter, which means packing the struct by hand, with a CK_ULONG whose size depends on the platform.

What this adds

• HedgeType, an IntEnum of the three CKH_* values: PREFERRED, REQUIRED, DETERMINISTIC_REQUIRED.
• SignAdditionalContext(context=None, hedge=HedgeType.PREFERRED) in pkcs11.mechanisms, modelled on GCMParams and CTRParams. The context is at most 255 bytes, as FIPS 204 allows.
• Mechanism.ML_DSA accepts it as mechanism_param for signing and for verification. Hedging only matters for signing; a token ignores it on verification.

As discussed in #249, ML_DSA without a parameter still passes a NULL parameter, and a raw bytes parameter still takes precedence, so existing code behaves as before.

Tests

tests/test_ml_dsa.py gains seven cases:

• sign and verify with a context, where another context or none must not verify;
• an empty context, which must match no parameter in both directions;
• deterministic signing, giving identical signatures;
• hedged signing, giving different signatures;
• a wrong parameter type;
• a context that is too long;
• a hedge value that is not a HedgeType.

The whole file passes against FreeHSM, a PKCS#11 v3.2 software token. I have not run it against the SoftHSMv2 and opencryptoki builds in CI, and I don't know whether they implement the context and the hedging variants. I will look at what CI reports here and mark the cases for whichever token lacks them, the way existing tests use Not and FIXME.