Migrates ECKey to stricter API

This pull request migrates the `ECKey` API to be stricter and force the user to be verbose about their intent instead of detecting their intent from the parameters.

This is done by the following three new functions:

* `ECKey.fromBuffer`,
* `ECKey.fromWIF`, and
*  `ECKey.makeRandom`

The default constructor `ECKey()` accepts a `BigInteger` and compression flag, and is what the other 3 constructors use to instantiate an `ECKey`.

A point of discussion is the change in behaviour by the constructor when dealing with keys outside of the `secp256k1` keyspace.
Previously, any key imported into `ECKey` would be automatically constrained/wrapped: `input.mod(ecparams.getN())`.
This pull request removes that implicit behaviour and instead asserts that the input is already constrained to be within the key space.

`assert(D.compareTo(ecparams.getN()) < 0)`

This removes an unnecessary `mod` operation, while also stopping confusion from users who might think that `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF` is a valid private key.
This behaviour still exists in `ECKey.makeRandom` as it must constrain the randomly generated key to within these bounds.

Although not necessary, I have maintained `toHex/fromHex` convenience wrappers, these exist until we can simplify down the test fixtures enough that it would not be huge amount of `new Buffer(..., 'hex')` and `toBuffer().toString('hex')` modifications just to maintain compatibility.