```
$ rebar3 shell
===> Verifying dependencies...
===> Compiling jiffy
Erlang/OTP 18 [erts-7.3] [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V7.3  (abort with ^G)
1> jiffy:decode(<<"[1e310]">>).
** exception error: an error occurred when evaluating an arithmetic expression
     in function  math:pow/2
        called as math:pow(10,310)
     in call from jiffy:finish_decode/1 (jiffy/_build/default/lib/jiffy/src/jiffy.erl, line 118)
     in call from jiffy:finish_decode_arr/2 (jiffy/_build/default/lib/jiffy/src/jiffy.erl, line 149)
2> jiffy:decode(<<"[0.2e310]">>).
** exception error: bad argument
     in function  list_to_float/1
        called as list_to_float("0.2e310")
     in call from jiffy:finish_decode/1 (jiffy/_build/default/lib/jiffy/src/jiffy.erl, line 120)
     in call from jiffy:finish_decode_arr/2 (jiffy/_build/default/lib/jiffy/src/jiffy.erl, line 149)
3>
```

That `310` could depend on my machine, since `math:pow/2` says it's a limitation coming from libc.

With this change, this still throws an exception, but it doesn't come
from math or erlang, but jiffy:

```
1> jiffy:decode(<<"[1e310]">>).
** exception throw: {error,{range,310}}
     in function  jiffy:finish_decode/1 (jiffy/_build/default/lib/jiffy/src/jiffy.erl, line 121)
     in call from jiffy:finish_decode_arr/2 (jiffy/_build/default/lib/jiffy/src/jiffy.erl, line 157)
2>
```

Signed-off-by: Stephan Renatus <srenatus@chef.io>

Finally got off my butt and started using EUnit.

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.