certtool: generate, parse, and manipulate X25519 and X448 pubkeys, privkeys, and certificates

I'm using certtool to generate certificates for use in CMS (S/MIME) for draft-ietf-lamps-samples.

The LAMPS WG requested some sample certificates using Curve25519. The verification certificates/signing keys (using EdDSA) were straightforward to generate, but the encryption certificates/decryption keys (using X25519) were not possible.

This series of changes to GnuTLS adds support for generating and handling X25519 and X448, though of course those certificates are not yet useful in a CMS context from GnuTLS itself without completing work on #1185.

I don't consider this series ready to go yet; it would help me to get three specific pieces of feedback from GnuTLS devs upstream:

• many of the commits in this series effectively duplicate code that was EdDSA-specific, and refers to these CFRG curves as "modern ECDH". A different approach would be to take the (non-visible) pubkey and privkey handling functions that are currently named *_eddsa_* and expand them to handle X25519 and X448 as well, since their data representations are identical to Ed25519 and Ed448 to the best of my understanding. If that is preferable to the current approach (less code duplication, but possibly some other entanglements), let me know and i can rework the series with that preference in mind.

• I'm not sure what tests I should add. Suggestions welcome!

• I've exercised this code enough to be able to generate X25519 certificates using an Ed25519 CA using certtool in the way that I'm comfortable with already, but i am not sure that I've handled every possible codepath where an X25519 or X448 certificate, private key, or public key might show up. Further review would be welcome.

Checklist

• Commits have Signed-off-by: with name/author being identical to the commit author
• Code modified for feature
• Test suite updated with functionality tests
• Test suite updated with negative tests
• Documentation updated / NEWS entry present (for non-trivial changes)
• CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout)

Reviewer's checklist:

• Any issues marked for closing are addressed
• There is a test suite reasonably covering new functionality or modifications
• Function naming, parameters, return values, types, etc., are consistent and according to CONTRIBUTION.md
• This feature/change has adequate documentation added
• No obvious mistakes in the code