Turns out this was never implemented correctly since it was referring to
the original bytes_per_iter atom.

In the original PR for `return_trailer` @vlm pointed out that I wasn't
using enif_consume_timeslice correctly. This fixes that by changing out
its called.

Previously we attempted to define the total number of bytes to decode or
encode in a single NIF call and then would consume as much of the
timeslice as we processed. This is wrong because we may start the NIF
call with less than an entire timeslice left.

The new approach is to define the number of bytes to encode or decode
per reduction and then iteratively call enif_consume_timeslice until it
indicates that we should return.

This is pretty much a generalisation of the use_nil option to support an
arbitrary atom.

This updates encoder errors to report the actual Erlang value that
caused the error. This should make it easier to debug errors when
generating JSON.

Rather than worry about truncation casting from a possibly 64bit value
down to a possibly 32bit size_t we just limit the total bytes per
invocation to 4G using an unsigned integer.

Thanks to @seriyps for the report.

Fixes #61

This adds a configurable limit on the number of bytes consumed by
the decoder before yielding back to the Erlang VM. This is to avoid the
infamous scheduler collapse issues.

The `jiffy:decode/2` now takes an option `{bytes_per_iter,
pos_integer()}` that controls the yield frequency. The default value is
2048.

Feed the lawyers.

Passes all eep0018 tests.