Define a consistant API

[pnmadelaine]

There has been discussion at cryspen about defining a consistant API for hacl-packages.
They came up with a proposal: cryspen/hacl-packages#255
It may be a good idea to adopt such a convention upstream.
We could also define a convention for the order of arguments.

Changing the API would definitely be a breaking change for users of the C code, so in some cases we should certainly keep the deprecated API around for a while.

Thus I suggest we:

• define a clear API for hacl and expose it clearly to contributors
• decide which deprecated functions need to be kept around
• wrap deprecated functions in the new API

[franziskuskiefer]

Some thoughts on ECDH/Signature APIs (re #710)

Signatures

The prefix would be something like Hacl_Signature_EcDsa_P256_, Hacl_Signature_EcDsa_K256_, Hacl_Signature_EdDsa_25519_
with functions sign, verify.

ECDH

The prefix would be something like Hacl_ECDH_P256_, Hacl_ECDH_K256_, Hacl_ECDH_25519_
with function ecdh.

Generic

The prefix would be something like Hacl_P256_, Hacl_K256_, Hacl_25519_
with functions private_to_public, mul, mul_base, verify_public_key, verify_private_key.

Some open questions

• Where to put the hash or is there a default hash algorithm?
• What's the default point encoding for the function i/o and what conversion functions should be exposed?
• Which additional functions need to be exposed, or are there some that shouldn't be in the public API?

[msprotz]

@pnmadelaine are we done with this? sounds like your (excellent) rewrite of the APIs with consistent names has landed, no?