haxe.format.JsonParser parses invalid multiline strings.

This throws on JS, because indeed `"foo\nbar"` is not a valid string literal (in JSON or even in JS).

```haxe
function main() {
trace(haxe.Json.parse('"foo\nbar"'));
}
```

But it works fine on e.g. neko: https://try.haxe.org/#00946d0A

As a result, we have invalid haxelib.json files uploaded to haxelib: https://github.com/lix-pm/lix.client/issues/197

So if we do anything (and I think we should), we'd have to probably fix any archives that are affected.

It does seem like PHP's `json_decode` also just accepts control characters within strings, with no way to disable this "feature". But I'm inclined to say that the standard parser should be strictly spec compliant and if people targeting PHP need spec compliance, they can rely on `-D haxeJSON` or wrap some PHP-specific solution. Python throws on the above input too.

Start at the haxe.Json.parse entry point and compare its behavior across JavaScript, Neko, PHP, and Python for strings containing raw control characters. Determine how strict JSON parsing should apply across targets, including the -D haxeJSON path. Done means invalid multiline strings are handled consistently with the chosen specification and the impact on affected haxelib.json archives is assessed.

Written by the indexing model from the issue text.