add labels option

[RoadRunnr]

Add a {labels, Labels} with Label = binary | atom | existing_atom | attempt_atom to control the how JSON labels are returned during decoding.

[RoadRunnr]

This is the more complex and complete alternative to #229.

I actually like this one better and would prefer this version to be merged!

[nickva]

Looking at some of the issues before a 2.0 release. I see a few variations of this PR (I'll close others and we can discuss here)

I am not against the idea, I could see a large json object saving quite a bit of memory when most keys are known already and they can be returned as atoms. What I think would be a bit odd, though, is the result we get from decode will then depend randomly on some other parts of the system creating atoms. Say, if we imagine loading json documents periodically, and there is some config system maybe adding a few atoms like 'key' or 'name' concurrently. Then, all of the sudden, the exact same document from before will now return with #{key =>...} as opposed to #{<<"key">> =>} before, just because something else created the key atom.

What about maybe passing these expected atoms in a list through the API and the decoder will only try to create atoms for those explicit set of items? Internally we could transform the list into a #{<<"key">> => key} map and look up parsed keys in there and the emit the atom if we find it? Wonder if that would work a bit more consistently.

Also, we'd have show that this would be a decent performance improvement vs doing it in Erlang as a post-processing step. At first sight, it may seem we'd be saving a lot of binary allocations, however for plain ascii strings (which keys are most likely to be) jiffy already does sub-binary references, so it tries to avoid extra binary allocations to start with anyway, and so it might not be as big of a win because of that.