Better handle String hashCode collisions in JsLookup

[htmldoug]

#186 is still exploitable when JsLookup is used (jsObject \ "foo") or jsObject.value is called directly.

Thankfully, the Reads macro doesn't use either of these approaches. Instead, it extracts fields from jsObject.underlying (typically a java.util.LinkedHashMap). If this approach is good enough for the macro, it seems to make sense to do for JsLookup as well.

jsObject.value is still vulnerable, but there are no remaining references to it internally after this PR.

Before:

[info] Benchmark                                           (n)   Mode  Cnt    Score    Error  Units
[info] JsonParsing_01_ParseManyFields.parseObject        10000  thrpt    3  170.811 ± 24.671  ops/s
[info] JsonParsing_01_ParseManyFields.parseObjectAs      10000  thrpt    3  163.436 ± 13.332  ops/s
[info] JsonParsing_01_ParseManyFields.parseObjectLookup  10000  thrpt    3    1.462 ±  0.077  ops/s
[info] JsonParsing_01_ParseManyFields.parseObjectValue   10000  thrpt    3    1.452 ±  0.144  ops/s

After:

[info] Benchmark                                           (n)   Mode  Cnt    Score    Error  Units
[info] JsonParsing_01_ParseManyFields.parseObject        10000  thrpt    3  174.182 ±  18.880  ops/s
[info] JsonParsing_01_ParseManyFields.parseObjectAs      10000  thrpt    3  158.034 ±  44.744  ops/s
[info] JsonParsing_01_ParseManyFields.parseObjectLookup  10000  thrpt    3  167.274 ±  54.709  ops/s
[info] JsonParsing_01_ParseManyFields.parseObjectValue   10000  thrpt    3    1.451 ±   0.111  ops/s

Relates to #193. @gmethvin @marcospereira