Make sure that you cannot create an invalid `SecretKey` in the first place.
Unbreaks the API.

[unbreaking-change]

It turns out I need to run `init` before pretty-much every FFI function,
which means that most everything would have to be marked unsafe if I'm
expecting the Rust user to do this. This is unacceptable -- users who
need to sacrifice safety for speed can just use the `ffi::` functions
instead.

Also, I noticed that I was locking up in `PublicKey::from_secret_key`.
Fix to return an error value -- unfortunately a breaking change since
it changes the function signature.

[breaking-change]

Simpler `random_32_bytes`.

As @dpc observes, embedded systems do not necessarily have allocators, so we
should avoid using them if it is not too much hassle. (And it is no hassle at
all.)

Verifying signatures does not require any randomness, but requires the user
to create a `Secp256k1` object nonetheless (this is just a way to guarantee
that `init` is called --- an alternate API would be to have an independent
unsafe `verify` function). If a Rng can't be created, rather than failing
the `Secp256k1` initialization, fail the functions that actually try to use
the Rng.

This way signing and verifying, which require no randomness beyond that input
to them, will work correctly.

To avoid checking for a working Rng on each call to `generate_keypair` and
`generate_nonce` (which is probably trivial next to the cost of actually
generating the randomness, but w/e, user knows best), the user should use
the generation functions in the `key` module, which take an Rng as input.

Fix unused imports and add a gitignore

The way compact signatures are working was explain to me:

https://github.com/bitcoin/secp256k1/issues/45