Fix: Non-integers were always parsed as strings, if storeAsString

[edgarsi]

Losing precision after the decimal point is almost always a non-issue. Using 'string' in such cases is usually worse.

[edgarsi]

To be frank, it isn't clear to me what the purpose of storeAsString is:

• If may be to retain full information. In this interpretation, my pull request is wrong.
• It may be to let the any parsed result x to be stringified without data loss, e.g. int64 identifiers for UI output. This was my concern.

If json-bigint is used as a drop-in replacement for parsing all jsons, it is safe to say we don't want to convert to string in cases where it isn't necessary, as it may break components expecting non-string types. There are several questionable cases:

• Integers larger than 2^53 - we do want to convert. Otherwise, why is json-bigint even used?
• Non-integers larger than 2^53 - ?. I am converting them, because they were converted prior to this PR, so converting creates the least amount of breaking change, while letting json-bigint claim "No integer part will ever be damaged by parsing". I don't know any use case for such numbers though, and have heard an opinion that non-integers should always be safe to round.
• Scientific notation - ?. To me, notation does not matter, only the number itself. But prior to this PR, any large numbers in scientific notation were parsed as number, including large integers. I am not changing that, though I disagree with the choice.