The Rng was only used for key generation, and for BIP32 users not even then;
thus hauling around a Rng is a waste of space in addition to causing a
massive amount of syntactic noise. For example rust-bitcoin almost always
uses `()` as the Rng; having `Secp256k1` default to a `Secp256k1<Fortuna>`
then means even more syntactic noise, rather than less.

Now key generation functions take a Rng as a parameter, and the rest can
forget about having a Rng. This also means that the Secp256k1 context
never needs a mutable reference and can be easily put into an Arc if so
desired.

This comes with a couple bugfixes and the following API changes:

  - Secp256k1::sign and ::sign_compact no longer return Result;
    it is impossible to trigger their failure modes with safe
    code since the `Message` and `SecretKey` types validate when
    they are created.

  - constants::MAX_COMPACT_SIGNATURE_SIZE loses the MAX_; signatures
    are always constant size

  - the Debug output for everything is now hex-encoded rather than
    being a list of base-10 ints. It's just easier to read this way.

kcov v26 now reports 100% test coverage; however, this does not
guarantee that test coverage is actually complete. Patches are
always welcome for improved unit tests.

This function can't fail, so no need to return a Result.

All of these were things that are (should be) guaranteed true no matter
what input is given to the API, barring unsafe operations on the data.

Now that you can't create secret keys by directly passing a Rng to
`SecretKey::new`, we need a way to allow user-chosed randomness.
We add it to the `Secp256k1`.

Rather than have global initialization functions, which required
expensive synchronization on the part of the Rust library,
libsecp256k1 now carries its context in thread-local data which
must be passed to every function.

What this means for the rust-secp256k1 API is:
  - Most functions on `PublicKey` and `SecretKey` now require a
    `Secp256k1` to be given to them.

  - `Secp256k1::verify` and `::verify_raw` now take a `&self`

  - `SecretKey::new` now takes a `Secp256k1` rather than a Rng; a
    future commit will allow specifying the Rng in the `Secp256k1`
    so that functionality is not lost.

  - The FFI functions have all changed to take a context argument

  - `secp256k1::init()` is gone, as is the dependency on std::sync

  - There is a `ffi::Context` type which must be handled carefully
    by anyone using it directly (hopefully nobody :))

Y'know, I can't for the life of me think what this was supposed to
be used for. Given that the library did not compile for several
months until last week, I assume there are no users, let alone
users of such a weird feature.

rust-secp256k1 was based off of https://github.com/sipa/secp256k1,
which has been inactive nearly as long as this repository (prior to
a couple days ago anyway). The correct repository is

   https://github.com/bitcoin/secp256k1

This is a major breaking change to the library for one reason: there
are no longer any Nonce types in the safe interface. The signing functions
do not take a nonce; this is generated internally.

This also means that I was able to drop all my RFC6979 code, since
libsecp256k1 has its own implementation.

If you need to generate your own nonces, you need to create an unsafe
function of type `ffi::NonceFn`, then pass it to the appropriate
functions in the `ffi` module. There is no safe interface for doing
this, deliberately: there is basically no need to directly fiddle
with nonces ever.

I'm taking advantage of the CC0 license on any of David's code to
give me permission to do this :). Almost all of it is my code by
this point so I am also morally in the clear.

-a

[breaking-change]

All tests pass, compile now

We can compile now, but not link -- there have been too many changes
in libsecp256k1 behind the scenes. Next commit :)

This reverts commit 98890907.

This is not ready for primetime -- the move prevention also prevents
reborrowing, which makes secret keys nearly unusable.

Using the `secretdata` library, we can store SecretKeys in such a way
that they cannot be moved or copied, and their memory is zeroed out on
drop. This gives us some assurance that in the case of memory unsafety,
there is not secret key data lying around anywhere that we don't expect.

Unfortunately, it means that we cannot construct secret keys and then
return them, which forces the interface to change a fair bit. I removed
the `generate_keypair` function from Secp256k1, then `generate_nonce`
for symmetry, then dropped the `Secp256k1` struct entirely because it
turned out that none of the remaining functions used the `self` param.

So here we are. I bumped the version number. Sorry about this.

The typesafe version could not accept illegally padded signatures because
`Signature` is a fixed-width type. Unfortunately such signatures are on
the blockchain, and we need a way to verify them.

Testing was done against python-ecdsa; python code in the test case
comments.

[breaking-change]