Add multi-part operations for asymmetric signature

[athoelke]

This adds the new operations for multipart sign and multi-part verify for asymmetric signatures (previous discussions suggested these should be ditinct types).

• Updated the Functionality chapter to indicate the availability of multi-part operations for signature (and added two missed additions in 1.4).
• Extended the introduction to Asymmetric Signatures to describe the multi-part operations, and how they extend multi-part capability to message-signature algorithms.
• Added/modified text in signature algorithms to reflect their compatibility with the mluti-part operations.
• Modified the Notes in the single-part functions which recommended the use of a multi-part hash operation for fragmented messages.
• Add new operation types and functions.

Fixes #319

[athoelke]

This needs to wait for the 1.4.1 publication to be finalised.

One aspect of the proposed API that might be debatable:

• I've added context parameters to the setup functions, which can be zero-length (as per the _with_context single part functions). This seems to be a better approach than adding an additional, optional to call, xxx_set_context()function to each operation - which adds additional states and complexity to the implementation.

[MarcusJGStreets]

Looks to be the obvious way to implement multipart sign and verify.

[athoelke]

• I've added context parameters to the setup functions, which can be zero-length (as per the _with_context single part functions). This seems to be a better approach than adding an additional, optional to call, xxx_set_context()function to each operation - which adds additional states and complexity to the implementation.

A fair counter-argument can be made for a separate function for a context based on the following observations:

• The XOF operation API has setting a context as a separate function.
• Many signature algorithms do not accept a context.
• Most (all?) protocols with asymmetric signature do not use a context (because the protocol predates the development of signature algorithms that have a context parameter).

So I will update this PR to pass the context in an optional psa_{sign|verify}_set_context(). This will have the same behavior as passing a context in the _with_context() signature functions - for an algorithm that does not support a context, it is permitted to call psa_{sign|verify}_set_context() with a zero-length context. [Note that this differs from the behavior of psa_xof_set_context() with an algorithm for which PSA_ALG_XOF_HAS_CONTEXT(alg) == 0]

[oberon-sk]

In our opinion the benefit of this new interface is quite small. Most signature algorithms are of the hash-and-sign type and can be used incrementally anyway. EDDSA and SLH-DSA do not work with the new interface because they need to traverse the message twice. ML-DSA has a hashed variant for the large message case. The only remaining algorithms are LMS/HSS and XMSS.

Besides its incremental nature, the new interface would have another advantage: it allows to use the operation object to store intermediate data. With the standard signature interface, all data has to be stored on the stack (in a heapless system). This is a severe problem for post-quantum algorithms like ML-DSA which need up to around 100k RAM.
However, the new interface supports sign and verify only, the RAM used for key generation (in psa_export_public_key()) must still be allocated on the stack.

And it is not a replacement for a low level ML-DSA interface in case mu is really "computed in a different cryptographic module".

[gilles-peskine-arm]

ML-DSA has a hashed variant for the large message case.

Unfortunately, HashML-DSA is forbidden by CNSA 2.0. In TF-PSA-Crypto, we have a customer who needs to sign a message that's scattered in RAM, and the protocol requires the use of pure ML-DSA, where CNSA compliance is a reason for not using HashML-DSA.