WIP iterative UntypedObjectDeserializer

[yawkat]

This is a WIP iterative implementation of UntypedObjectDeserializer. (see #3416 (comment) )

I looked at the existing JsonNodeDeserializer impl, and it is a bit better than this one (it uses a queue, and no intermediate worker objects, unlike this impl). However I don't think that approach can be easily adapted to work with arrays, it relies on adding the child collections to the parent immediately, which can be done with ArrayNode and could be done with List, but can't be done with arrays because they have fixed size (need to add to the parent after it's done).

Things left to do:

• compatibility: probably need to keep the protected methods, and the Vanilla serializer class
• perf: old impl had lots of small optimizations (e.g. for <=2-element lists), need to test how much perf this impl lost and do some optimizations for it
• specialization: just one impl for now. old impl had a simplified "vanilla" impl with fewer checks (e.g. no special list deser). could do the same with this approach. could also use a separate queue-based impl (like JsonNodeDeserializer) for the case that doesnt need USE_JAVA_ARRAY_FOR_JSON_ARRAY

I've run the databind tests for this draft, and they pass, or at least don't fail more than without the changes. There are some tests that I think fail for me because I use java 17, not sure what's up with that, but they seem to be unaffected by these changes.

[cowtowncoder]

Alas, Vanilla instance is performance-wise significantly faster than having to consider possible custom deserializers... so ultimately I'd like to retain this distinction. And/or at least measure performance difference in case I am wrong that there is significant difference.

[cowtowncoder]

First of all: thank you for submitting this.

I find it bit tricky to review, due to diffs being... well it's non-diffable, due to nature of changes.
So once all this silly CVE nonsense dies down, I need to really understand code, changes.

I think my immediate concern is performance. I suspect changes would have non-trivial negative effect in throughput: existing implementation is quite optimized, guided by extensive benchmarking (using https://github.com/FasterXML/jackson-benchmarks/).
It might be good to benchmark throughput using jackson-benchmarks project's "Untyped" case, with PR and base 2.14 (or perhaps just 2.13 as 2.13 and 2.14 before changes should perform about the same).

[cowtowncoder]

I ended up fixing this via #3473 which is sort of based on earlier JsonNode deserializer changes; closing this one.
Thank you for suggesting it; it helped with the actual changes!