Consider switching to a nettle backend

I'm a huge fan of [libnettle]. It's really small, well-written, and easily auditable. We could vendor it and statically link to it. Switching would solve issues like #15. It would avoid the dangers of calling out to potentially many different openssl versions.

As an added bonus, it would allow us to compile bcrypto to web assembly (we could add a fourth wasm backend). Nettle compiled to wasm doesn't seem to be significantly faster than our JS backend. Furthermore, google has pretty much ruined any possibility of using web assembly in the browser due to their arbitrary 4kb limit for synchronous wasm module loading (once the mass migration to firefox begins, this will be less of an issue). That said, a wasm backend would compensate for the lack of constant-time functions in the JS backend (assuming v8's wasm vm is actually doing that stuff in constant-time -- who knows what it's actually doing behind the scenes).

I currently have a [development branch] utilizing nettle. It supports pretty much everything, including a custom implementation of bip-schnorr.

I believe nettle will include ed448 support within the next version or two, which would allow us to drop most of our custom C code.

The downsides:

1. It's slower than openssl, especially for hashing. EC is also relatively slow (in nettle, _nothing_ is done in variable time, even during verification).
2. It doesn't support secp256k1 (we could still use libsecp256k1 for this, but it would be nice to support nettle's ecdsa backend as an option).
3. The build becomes longer and more complex.

For #1, we could optionally allow for openssl support just for fast hashing.

As far as #2 goes, there's an unfinished [patch] for secp256k1 on the nettle mailing list, but it seems to be missing the most important parts (e.g. the reduction/modulo functions). We would have to write our own reduction functions for the order and prime (we might be able to re-use the libsecp256k1 scalar reduction function, but the prime reduction is probably useless to us since it uses a different word size than gmp limbs). Anyway, not super important right now.

No solution for #3.

[libnettle]: https://github.com/gnutls/nettle
[development branch]: https://github.com/bcoin-org/bcrypto/tree/nettle
[patch]: http://lists.lysator.liu.se/pipermail/nettle-bugs/2017/003373.html

Start by reviewing the linked nettle development branch and the existing OpenSSL and JavaScript backends. Compare the branch's supported algorithms and build changes with the current project, then determine whether vendoring and statically linking nettle can cover the required functionality. Done would require an agreed backend design, a working build, and preserved algorithm support.

Written by the indexing model from the issue text.