ECDH Buffer to BN conversion loses leading 0s which are needed in webcrypto on some browsers

[jackkleeman]

I have verified here:
https://runkit.com/jackkleeman/58e63d3546216b001451a645
That a buffer will lose a leading 0 byte when converted to a BN, and when this is converted to base64 for use in JWK format, this base64 will also have no leading 0. This is a problem because chrome rejects base64 jwk x and y values which don't have the full 32 bytes (silly I know):
https://chromium.googlesource.com/chromium/src/+/master/components/test/data/webcrypto/bad_ec_keys.json#138
Therefore, 1 in 256 (or possibly 1/128) keys will be invalid when unmarshalled to JWK , because their base64 string will not have the leading 0 byte. I am not sure what the simplest way to fix this is (maybe an optional pad-to-length input to the toBase64 util function?), although a test case is fairly trivial, generate a bunch of ecdh keys until one has a leading 0 byte.

cc @JustinDrake good job for catching this