Initialization design

[CodesInChaos]

This is a follow up to the the initialization discussion in the Support assembly ed25519 with Python extensions issue.

1. I don't like reinit.

   Forks should only affect the rng and it should detect it automatically (check process id or something).

   Having to call this adds complexity and doesn't interact well with modular applications. The part doing the forking probably doesn't even know there is such thing as libsodium.

2. I don't like shutdown

   Shutdown essentially can't be called in a modular application and I don't see when it'd be useful. Just leave it to the OS to free the memory when the process terminates.

3. Current implementation of init is not threadsafe. The flag is set before the initialization completes. So on a second thread init can return before initialization is complete. BOOM.

   Just take a normal lock at the beginning of the init function and release it at the end.

   If you really want you can use a double checked lock, but getting it right is tricky. There are subtle issues related to the memory model.

[jedisct1]

A normal lock means introducing a dependency on pthreads, and I really want to avoid that.

reinit() and shutdown() are gone.

init() can be called more than once but is not thread-safe. It probably shouldn't even try to be.

Actually all these issues with init are due to the fact that the current API doesn't take any context.
So another way to go is to replace all the crypto__() functions with sodium__(, ...) and provide crypto_*() wrappers that always use the reference implementations.