Adding support for wobbly strings to On Demand and lossy trancoding from escaped (with replacement)

[lemire]

Some users receive strings that cannot be decoded into valid UTF-8 due to a bad sequence of escaped code points. A reasonable solution is to fallback on WTF-8. This is allowed by RFC...

When all the strings represented in a JSON text are composed entirely of Unicode characters [UNICODE] (however escaped), then that JSON text is interoperable in the sense that all software implementations that parse it will agree on the contents of names and of string values in objects and arrays. However, the ABNF in this specification allows member names and string values to contain bit sequences that cannot encode Unicode characters; for example, "\uDEAD" (a single unpaired UTF-16 surrogate). Instances of this have been observed, for example, when a library truncates a UTF-16 string without checking whether the truncation split a surrogate pair. The behavior of software that receives JSON texts containing such values is unpredictable; for example, implementations might return different values for the length of a string value or even suffer fatal runtime exceptions.

Note that the original input must still be UTF-8. And we will continue to validate for UTF-8 by default. Users will need to call a specific function (get_wobbly_string()).

We also adding a Boolean parameter to our get_string() methods so that replacement characters are inserted in lieu of errors (lossy decoding).

The DOM kernel will not be affected.

Fixes #1944