Update test "compiling standard JSON (invalid JSON)" to be nlohmann::json compatible

[aarlt]

The test is trying to parse {invalid. Doing so with nlohmann::json will create the following error:

{
  "errors": [
    {
      "component": "general",
      "formattedMessage": "[json.exception.parse_error.101] parse error at line 1, column 2: syntax error while parsing object key - invalid literal; last read: '{i'; expected string literal",
      "message": "[json.exception.parse_error.101] parse error at line 1, column 2: syntax error while parsing object key - invalid literal; last read: '{i'; expected string literal",
      "severity": "error",
      "type": "JSONError"
    }
  ]
}

This PR updates the expected error message.

[cameel]

Is this meant to be merged after we update to nlohmann-json? Because right now the binary will still give you the old output.

[cameel]

Note that currently this already allows two different messages. Probably because the message already changed in the past and some compiler versions will generate one and some the other. Those older messages can still happen since solc-js is meant to support all compiler versions, so you should add the new message as another alternative instead of replacing the old ones.

[cameel]

By the way, I'm not sure if exposing the [json.exception.parse_error.101] part to the user is a great idea. We already have our own error type here and this is an implementation detail showing through. I'd filter it out in solc if that's no too complicated.

[aarlt]

I don't know. I don't see any value in removing such information.

[cameel]

We discussed this on the chat, so I'll just repost the relevant bits here:

It would be better not to have this if it's easy to get rid of. It's something that would be more relevant in a debug message, but this is not an internal error, it's a normal parsing error meant for the end user. Those should be formatted without extra cruft, with things like error type being properly accounted for via the fields we already have.

I mean, I was assuming it must be pretty simple to do. Like, instead of printing exception.what() print just the field containing the message.
But actually not sure now if that message is even exposed. https://json.nlohmann.me/api/basic_json/parse_error/ does not mention it.
Also, apparently this is less of an internal detail than I expected. The numeric codes are even officially documented: https://json.nlohmann.me/home/exceptions/

So maybe it's ok after all. Just the way it's formatted makes it look like something internal. The class name there is just redundant. The error codes seem to be unique and showing that would have been enough.

Also it bothers me a bit how this introduces a new layer of error codes that's not connected to our own error codes.
I don't think the compiler should really be leaking internal implementation like that in its errors.
On the other hand doing it properly might not be easy, so I'm not saying to jump into it. We probably don't have time for that. Just still, I don't like it :)

[coveralls]

coverage: 84.537%. remained the same
when pulling 840f3b1 on fix_for_nlohmann_json
into 6c2d135 on master.

[cameel]

Is this meant to be merged after we update to nlohmann-json?

I mean, I'm wondering why you need this in solc-js already if solc on develop does not produce this output yet and shouldn't be causing any problems here.