signed integers are handled incorrectly

This change corrects two problems with signed integers, one on the encoding side and one on the decoding side.

The decoding problem is fairly simple: the existing code treats the sign bit as a one's complement operator.  Per BER 8.3.3, integers are encoded in two's complement form.  Therefore instead of negating the existing value, we need to subtract a value that depends on how long the integer encoding was.  This allows the code to correctly decode the values found in the Layman's Guide 5.7.

The encoding problem is more annoying: the existing code violates BER 8.3.2 by encoding all negative integers using 4 bytes.  This occurs because, apparently, the literal 0xff800000 in Javascript is the unsigned integer 4286578688, as seen on TV:

```
> process.version
'v0.10.24'
> 0xff800000
4286578688
> 0xff800000 >> 0
-8388608
```

As such, the equality check in the second clause on line 81 of writer.js does not pass even when in fact the bitwise integer representations match (because, of course, they're compared as floating-point values, not bit strings).  To avoid this, because ASN.1 integers are always signed, we simply need to ensure that this test is done using signed values.  When we write the resulting byte, however, we need to discard the sign bits.

Test cases added.  All existing and new tests pass.