Co-Authored-By: Stephan Renatus <srenatus@chef.io>

We don't do fishy things like type punning so it really isn't
necessary, and supplying it prevents certain optimizations.

This greatly increases the performance of long string encodes as
we won't need to copy intermediate results over and over.

If the input contained a mismatched end-of-array/object, the stack
could become empty before a call to dec_curr, which would look
beyond the bounds of the stack. If the value at this invalid
position happened to be st_array, we would pop too much from the
stack and overwrite the data that came before it.

This commit fixes this by letting dec_pop return the previous
state or st_invalid if the stack is empty, letting us exit
gracefully if the state isn't what we expect it to be.

dec_pop_assert is identical to the old dec_pop, tearing down the
emulator on internal errors.

This is a wee bit more cache-friendly than using a std::set with
string keys.

We requested atoms in latin1 and then handled them as utf-8,
erroring out on some valid atoms and performing pointless
validation on others.

enif_get_list_cell fails when the list is empty.

number of items on `hexvals` is 128 while table size is 256, so
remaining 128 items are filled with zero. As a result, values in
\xf0-\xff will be treated as zero while should be rejected.

Without this, call to decode with copy_strings option in an
application will make Dialyzer complain when using the exported type for options

Some users of Jiffy have experienced issues when decoding large JSON
documents. Normally Jiffy expects smallish documents and returns any
strings as sub-binaries. When dealing with large documents these
sub-binary references can keep a large amount of RAM around unless the
user goes through and applies `binary:copy/1` on every string returned
from Jiffy. This however causes a large amount of CPU usage to do
something that Jiffy could do as it builds the JSON structure.

The `copy_strings` decoder option does exactly this. Instead of
returning sub-binaries Jiffy now copies every string into a newly
allocated binary. Users report that this fixes the memory issues while
also not negatively affecting performance significantly.

You can no optionally request that keys are deduplicate inside of Jiffy
instead of having to perform that operation in Erlang.

When "\u"-escaping a Unicode character, the esc_extra value doesn't
need to include the number of bytes in the input string.  That is, if
a three-byte UTF-8 character is being escaped to a six-byte "\uXXXX"
sequence, esc_extra only needs to be increased by 3.

Cleanup after new enc lands

For some reason I left a 377KiB test case checked in. Replacing this
with a generated test case is obvious in hindsight.

Windows appears to not enjoy relative path names for exectuables so
hopefully this fixes things there.

Fixes #83

Apparently hex only includes some files by default but not others
rather than a sane default of anything except for VCS directories. So
now I also get to maintain a list of files in my .app.src.

Apparently rebar3 can't generate a sane version number from Git tags and
adds a bunch of BS build number and ref tags which hex.pm then rejects.
Given that I can't find any documentation on how that works and reading
code is an exercise in over engineered abstractionism I've succumbed to
the demoralizing conclusion that I'll just have to go back to the dark
ages and maintain my versions both in source and in version control.

A call to `jiffy:encode(Term, [use_nil]).` will currently cause dialyzer
to issue a warning because `use_nil` is not included in `encode_option`.
This appears to just be an omission.

Add support for rebar3

Allow Jiffy to be used easily in projects using either rebar 2 or 3.