Just trying to be a bit more thorough in the Makefile targets.

This runs a `git clean -fxd` to revert to a pristine Git clone.

I've had reports that HTTPS seems to fail a bit more often than the Git
URLs. I've seen this before as well so I've gone ahead and switched
protocols for the clone.

As it turns out I did not understand the documenation for
load/upgrade/unload correctly. load/upgrade are called conditionally if
there's code in the VM for the NIF. Ie, no code means load is called,
where as if code exists, upgrade is called.

unload is called regardless once per load/unload. This means that
load/upgrade in Jiffy's case will each create a state object and unload
will free it each time. I was missing the fact that unload is called
every time and hence I don't need to clear the state in upgrade.

The docs aren't entirely clear on the order of calls for upgrades so
this is mostly just in case old_priv ever happens to not be what load
returned in priv.

By default Jiffy is quite strict in what it encodes. By default it will
not allow invalid UTF-8 to be produced. This can cause issues when
attempting to encode JSON that was decoded by other libraries as UTF-8
semantics are not uniformly enforced.

This patch adds an option 'force_utf8' to the encoder. If encoding hits
an error for an invalid string it will forcefully mutate the object to
contain only valid UTF-8 and return the resulting encoded JSON.

For the most part this means it will strip any garbage data from
binaries replacing it replacement codepoint U+FFFD. Although, it will
also try and the common error of encoding surrogate pairs as three-byte
sequences and reencode them into UTF-8 properly.

* Update rebar to a more recent version
  * Update rebar.config for deprecation warnings
  * Allow people to export the REBAR environment variable to use
    their own version of rebar
  * Fixed `make clean`

There was a bug that was resetting the extra amount of space needed when
encoding unicode characters with the `uescape` option enabled.

I had a silly direction mistake in a bit shift that was causing the high
portion of all combining characters to be printed as \uD800 which is
obviously wrong. This bug only affects people using the non-default
uescape option during encoding.

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.

Fixes #15

jiffy:encode/2 now accepts a 'pretty' option that will format the JSON
output using two-space indents.

I need to fix this so that object sizes don't explode when generating
larger values. Basically, as the type generator recurses is should be
adjusting the size 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.

Not only was I not actually sending atoms to Jiffy, the test will end up
exhausting the atom table and crashing the Erlang VM.

Big thanks to Dmitry Groshev [1] for help getting PropEr tests into
Jiffy. These generate valid EJSON to check parsing as well as check
that random inputs don't cause segfaults or other nasty effects.

Future improvements would be to write a JSON generator as well as a
version that introduces known errors into the binary for checking known
parsing errors as well.

[1] https://github.com/si14

Fixes: #10

Rebar's eunit command wants to try and compile anything named *.erl in
the tests/ directory which causes errors with the test expectation
files. Rather than write a patch for rebar it was easier to just rename
everything.

It was possible to pass some types of invalid UTF-8 through Jiffy's
encoder. Specifically, if uescaping isn't used, values that would decode
from 0xD800 to 0xDFFFF, 0xFFFE, 0xFFFF, and values greater than 0x10FFFF
would not be flagged as invalid. Now they are.

The encoding length for unicode values was applied to the wrong index
variable.

Thanks to Paul Guyot for the detailed bug report and fix.

Fixes #7

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

Fixes #5

Multiple error reports on this.

Fixes #6

Based on the buffer doubling scheme in Yajl. This seems to make
Jiffy's encoder times less spikey, but I'm still a bit slower. It
appears to be related to floats or memory handling. Not sure how
to track this down.

The encoder can now return \u escaped unicode data instead of leaving
it as UTF-8 byte sequences. This done like so:

    Eshell V5.8.3  (abort with ^G)
    1> jiffy:encode(<<240, 144, 129, 128>>, [uescape]).
    <<"\"\\uD800\\uDC40\"">>

The encode and decode functions now return the value directly without
being wrapped in a tuple on success. If there is an error, it is
thrown. This is to more closely match the semantics of term_to_binary
and binary_to_term.

Feed the lawyers.