RFC6979 Test Vectors

Depends on #150.

This pull request adds RFC6979 compatible test vectors; and amends the implementation to adhere to them.

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.
**It should be noted that in almost all cases, the SHA-256 hash used is calculated *outside* of `ecdsa.sign`, and is therefore not explicitly present in the amended code itself.**

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.


**edit:** This is a sensitive area, so please if you have reviewed the code (and in depth), please note that here.  I'd prefer not to have this merged until at least 2 or 3 +1s.