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]