Allow customizable "reading" of JSON maps

[kevmoo]

Allows aliasing values to different names or computing a single
field value from any aspect of the source JSON map

Fixes #144
Fixes #888

[jakemac53]

Should readValue also return a T here to give better static checking? In general the relationship here between the _CastFunction and readValue params is a bit murky to me.

[kevmoo]

Will investigate...

[kevmoo]

So this is a bit weird.

readValue is meant to be pre-converter. So it should return a JSON-ish result. that then goes through any associated converters, etc.

If one wants readValue to return the field type, they have to also create a converter.

I pondered doing the logic where readValue just takes over ALL conversion logic, too. But that gets tricky.

[jakemac53]

Ya, that is what I was wondering about. This would cover some number of use cases, where one or more json fields can be merged into a new json-like field, but its a bit indirect for others. For instance you might have people actually returning a Map from readValue, built from some other fields, and then deserializing that map into some class in the regular conversion function.

Ultimately I think this choice is probably fine, but I would clarify things in the documentation?

[kevmoo]

Added more docs. PTAL

[natebosch]

I pondered doing the logic where readValue just takes over ALL conversion logic, too. But that gets tricky.

Tricky for users or for this library?

It feels like a simpler concept to document if readValue does all the work instead of coordinating with some other uncoupled concept with no static types in between...

[kevmoo]

It could be both. Imagine a case where I just want to rename a field foo -> bar but the type is something complex like Map<int, List<Duration?>>? – that's a bear to rewrite for the user.