Fix bug that assumes toByteArrayUnsigned() always returns 32 bytes.

To reproduce this bug, try entering the following XPRIV:
<code>xprv9s21ZrQH143K3GMYVMZBZCGProVPNqGXRXz3ktUYt1rXG813HhysPLeNj8AfahpW2d4Tc678FMYndMrw9sqUFuLD2mug9pwojMuNusRbsv9</code>
and use the following derivation path: <code>m/44'</code>

The correct derived private key should be:
<code>xprv9tzN9JZpuT1wiz7y2qsBnjttAxvUQcdjCCEVXdMQmp32FeX4vGve5PA7yFan15Jo71HrxsA6VAnpqWW2JNoaXaLe3NeqWKoYS76AEBfioN7</code>
but the code was previously outputting:
<code>DeaWiSNc9gKmPJgBaytskvDH3Cz4tebKSjxu9t2hSyGVx1gt2xdGPVXjPHoUQd9LBRpcJQDbFdQdEAzqWq2eVeErNLsGwEEWGEGgArZjHap4aP</code>

This was as a result of line 185 in bip32.js calling
<code>this.eckey.priv.toByteArrayUnsigned()</code> without verifying that the
returned byte array had the correct length required for serialization
(32 bytes).

Furthermore, errors would cascade down the path dangerously unnoticed.
For example, using the path <code>m/44'/0'</code> with the XPRIV mentioned above,
the correct derived private key should be:
<code>xprv9xUGaEZ5EBM1tGE9Ujp2EaPC85Pt8PRwMSmk53rvy3YmJbg6jBZM3mybraxFBWFgzrfhEhiiugDMArUqiGDSQF3zHL8wY6AZBXE77Jq2utJ</code>
however the original code would give:
<code>xprv9xUGaEZ5EBM1ueG3H1yNEgQuk9ivpzaHhVbp58hcCJSyrinvZC3k6uvzobs6Av5UmLvjfRQK6AWq2fL9ej27wjr3BURJFddYzvovFYngqLS</code>

This was quite dangerous as there is nothing obviously wrong with the
output. This cascading bug was due to line 254 in bip32.js which also
incorrectly assumed that toByteArrayUnsigned() always returns a 32 byte
long array.