We had added a necessary include directory to build.rs but not updated the
library on crates.io, so dependencies of rust-secp were failing to build.
(However, on my local system I had secp installed in /usr/local/include,
so I did not notice the problem until Travis pointed it out on a different
project!)

Pieter moved some stuff I need into the contrib/ directory which does
not expose anything through the shared lib, so I need to statically
link.

I might also use this to do evil things to expose the SHA256 code
in libsecp, but not for now ;).

This should be a major version number since I changed public constants
in the ffi module. I'm not doing so as the invariant "will the constants
be meaningful to the underlying library" has not changed.

In general this library's version numbers do not map well to the
underlying library, which is as-yet not versioned at all, so users
need to always be running "the lastest" rust-secp256k1 anyway, and
semantic versioning can't really be used meaninfully. So this is a
bit of a judgement call.

[BREAKING CHANGE] Make PK::from_secret_key() return a Result; change from_ffi functions to From impls

If you try to call PublicKey::from_secret() key with an incapable context it will
now return an error. Before it would pass through to the underlying library which
would terminate the process, something we strive to never expose.

Also change the from_ffi functions on various types to impl's of From to be more
Rustic. We cannot change the from_slice functions because they have error returns.

Also add a Secp256k1::without_caps() function which creates a capability-less
context. I find myself using this in so many places downstream that it seems
appropriate.

RecoveryId tag i32 should be public to allow library users to access it.

library users the ability to create RecoveryId objects and convert them to i32 equivalents, without allowing users to create invalid ones.

RecoverableSignature now supports compact serialization via FFI, with…

I didn't mean for both of these to go into the same commit, but given how
small the ECDH code was, and the fact that no commit prior to this one will
compile (as both libsecp256k1 and rustc have changed so much), I'm letting
it slide.

This is a new libsecp256k1 function which does additive blinding
for nonce generation during signing.

This is kinda silly but gets me 100% coverage from kcov

There are a lot of cases in rust-bitcoin where we need a `Secp256k1`
which doesn't need any signing or verification capabilities, only
checking the validity of various objects. We can get away with a bare
context (i.e. no precomputation) which can be cheaply created on demand,
avoiding the need to pass around references to Secp256k1 objects everywhere.

API break because the following functions can now fail (given an insufficiently
capable context) and therefore now return a Result:

    Secp256k1::generate_keypair
    Secp256k1::sign
    Secp256k1::sign_compact

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.