Consider using `Number.isSafeInteger(i)`

[dlongley]

• Does this need more edge case checks?
• Might consider at least having a zero and negative int check. Probably Number.MIN/MAX_SAFE_INTEGER too.
• Does this need the reverse checks of data with a plain int and query with an int string? I think the code would handle that?
• Parsed JSON itself with native ints will (probably?) be limited to Number.MIN/MAX_SAFE_INTEGER. But if both sides had strings with non safe int values, I think this starts to lose precision and would cause matching failures. In any case, havoc will probably happen. Is that important to handle here?

Example:

> Number.MAX_SAFE_INTEGER
9007199254740991
> a = parseInt('9007199254740992')
9007199254740992
> b = parseInt('9007199254740993')
9007199254740992
> a.toString()
'9007199254740992'
> b.toString()
'9007199254740992'
> a.toString() === b.toString()
true

• One solution might be to use BigInt(x), but that's introducing radix prefix issues and returning BigInts vs ints for comparison and no doubt has odd issues.
• Another solution is to specifically not handle these issues and after the parseInt, check if Number.isSafeInteger(i) is false, then return x. Would need some tests to make sure that works and simply refuses to match those non-safe string values for now.

Originally posted by @davidlehn in #79 (review)

---

We probably only want the Number.isSafeInteger(i) check, not any BigInt checks. We're only interested, I think, in converting integers for array indexing processing and interoperable JSON numbers.