Adds BI.toPaddedBuffer and toBuffer

This pull request adds the following functions to the `BigInteger` prototype, with the intention of merging them in some form upstream (to `bigi`) in the near future.

* **BigInteger.fromHex**
 Unlike `new BigInteger(hex, 16)` or `BI.fromBuffer(new Buffer(hex, 'hex'))`, this function will ensure that the hex is at least 2N byte length.  This could probably be done in a more strict way, and will be best done at the implementation level of BigInteger rather than using `Buffer`s as an intermediary.
It is up for discussion whether `ECKey.fromHex` should have these assertions, if not more.
Unfortunately both `ECKey.fromHex` and `BigInteger.fromHex` will both interpret `11ZZ` as the hex string `11` (stopping on the `ZZ`, and not failing), as this is the inherent underlying behaviour of `Buffer` and `new BigInteger(hex, 16)`.

* **BigInteger.prototype.toBuffer**
 As straight forward as it sounds, is literally just an convenience wrapper around `new Buffer(this.toByteArrayUnsigned())`.  This will avoid pointless code duplication everywhere when `ecdsa` is ported to using `Buffer`s.

* **BigInteger.prototype.toHex**
 Like `ECKey.prototype.toHex`, this is just a wrapper around `toBuffer` except with a hex-string return value.  Unlike `BigInteger.prototype.toString(16)`, this is guaranteed to give a 2N byte length output.

* **BigInteger.prototype.toPaddedBuffer**
 This function centralizes all the padding efforts throughout the library to one place, and under test.  It may be debatable whether this functionality is related to the BigInteger at all, as with all these serialization/encoding efforts, however I think it is an important step in the right direction.

Finally, the added assertions showed a broken test which was just 'appearing to work' in `test/ecdsa.js`.  A `BigInteger.ZERO` was being used as input for `BigInteger.fromByteArrayUnsigned`, which when given an object, defaults it to an equivalent of `0`.