std/crypto: add (X)Salsa20 and NaCl boxes

[jedisct1]

The NaCl constructions are available in pretty much all programming languages, making them a solid choice for applications that require interoperability.

Go includes them in the standard library, JavaScript has the popular tweetnacl.js module, and reimplementations and ports of TweetNaCl have been made everywhere.

Zig has almost everything that NaCl has at this point, the main missing component being the Salsa20 cipher, on top on which NaCl's secretboxes, boxes, and sealedboxes can be implemented.

So, here they are!

And clean the X25519 API up a little bit by the way.

[zigazeljko]

Why does X25519 use a KeyPair struct with separate fields for private and public keys, but Ed25519 uses a single [keypair_length]u8 as a keypair?

[jedisct1]

Ed25519 will move to using a KeyPair as well.

These are quite different from X25519 key pairs, as the actual secret key is not stored. What is stored as a "secret" is a concatenation of the seed and the public key. Changing that interface requires too many changes unrelated to the topic of this PR, so that will be done separately.

[jedisct1]

Not a lot of changes needed to move ed25519 key pairs to a struct, after all. So, added here as well.

[zigazeljko]

Why is the secret_key still 64 bytes? Since the public key is already stored as a separate struct field, the secret_key only needs to store the seed.

[jedisct1]

EdDSA requires the public key in addition to the secret key for signing.

If the public key has to be recomputed every time a message has to be signed, it has a noticeable performance impact.

In addition to that, EdDSA fails catastrophically if the wrong public key is used to compute a signature.

For these reasons, the most common way to serialize EdDSA secret keys is as an aggregate of the seed (the secret scalar wouldn't be enough) and the public key.

[daurnimator]

sorry I didn't finish my review before this was merged >>