I pulled in a lot of tests from the double-conversion test suite to make
sure we don't accidentally break behavior in the future.

Floating point numbers are no longer encoded as a one to one mapping
of their binary representation, but as short as possible (while still
being acurate). The double-conversion library [1] is used to do the
hard work.

The ECMAScript compatible conversion is used.

[1] https://code.google.com/p/double-conversion/

Numbers like 1.0 were being encoded as <<"1">> which can lead to a bit
of confusion. This merely checks if a decimial point exists and if not
it appends ".0" to the value.

Looks like there's a slight difference in the number of significant
digits supported across platforms in strtod. This just adds a couple to
force it into the bignum code.

I was accidentally truncating numbers when casting to long on
machines that don't have longs that are 8 bytes.

Fixes #5

Feed the lawyers.

Any number that can't be decoded in C is now passed back
to Erlang for decoding.

Large numbers passed to the encoder will make it through
and be processed in Erlang after the main encoding
process.

Passes all eep0018 tests.