RFC6979 Test Vectors

Depends on #150.

This pull request adds RFC6979 compatible test vectors.

The test vectors were sourced from https://bitcointalk.org/index.php?topic=285142.40 and https://bitcointalk.org/index.php?topic=395761.msg6357583#msg6357583.

A major change was in the types of parameters accepted by the `deterministicGenerateK` function.  [RFC6979 specifies](http://tools.ietf.org/html/rfc6979#appendix-A.1.2) that the input is a SHA-256 message with a byte length of 32.
This was not previously enforced.

Secondly was the length of `D` as used by the `HmacSHA256` function.
The RFC states that:
>  Note: Although the specific value of x would numerically fit in 160 bits, i.e., 20 octets, we still encode x into 21 octets, because the encoding length is driven by the length of q, which is 163 bits.

For our curve `secp256k1`, the `length of q` is 256 bits, aka 32 octets/bytes; therefore `D` is enforced to adhere to that padding length through the use of `toPaddedBuffer(32)`.

Finally some assertions were added to check that `k` is a reasonable value.  The RFC specifies that if a reasonable `k` value is not found, that you loop until one is found.
This is so statistically unlikely, that for now, it simply ignored (with assertions).

This same approach is taken for the `r` and `s` values:
```
assert.notEqual(r.signum(), 0)
...
assert.notEqual(s.signum(), 0)
```
Which previously went unchecked.