Update the test schema to make expErrors "array" only

[mihnita]

Right now that is an array or a boolean:

"expErrors": {
  "description": "The runtime errors expected to be emitted when formatting the message. If expErrors is either absent or empty, the message must be formatted without errors.",
  "type": [
    "array",
    "boolean"
  ],
  ...

Why:

1. Something that can be one of two different types makes it harder to consume the json from statically typed languages
2. It is not useful in any way.
   The description already says "If expErrors is either absent or empty, the message must be formatted without errors". That covers the possible expErrors = false.
   So we already have 2 ways to say "nothing fails", we don't need 3 ways.
   And if we expect an error, then we should say what that error is, not just say "yes, we expect errors" (expErrors = true).

The only use of expErrors as boolean right now is in test/tests/functions/currency.json, and all instances are "expErrors": false.
Which is not needed (as per description missing expErrors means no errors).
And that is what we do in all other tests, we don't specify expErrors when none are expected.

[mihnita]

I am wrong, there are several files with expErrors boolean, not just currency.json

But all use expErrors = false (which can very well be missing, or an empty array).

The one exception with expErrors = true is test/tests/fallback.json

Which I think is cleaner if we specify why the failure, not just true.

[mradbourne]

I support this. I think we have enough tests now to say that we're not getting much value from { expErrors: true } and may as well simplify 👍

[mihnita]

If we are into simplifying this area, at this point I think we can also make the expected errors simple strings.
Right now they are objects with a single key, always "type".

So instead of:

"expErrors": [{ "type": "unknown-function" }, { "type": "bad-selector" }]

we can say:

"expErrors": [ "unknown-function", "bad-selector" ]

Less verbose, and the exact same info.

It does not mean that implementations are forced to represent the errors as strings instead of being typed.
It only means that the test suites might have to "massage" the direct result of the parsing,
or at the point where it compares the real error (an object) with the expected on from json (a string).

We already forced C/C++/Java to do all kind of "massaging" of the data loaded from json.

It would be easy for an implementation to change a test from:

// Compare two Error objects
if (realError == expectedError) ...

to:

// Compare two strings
if (realError.type == expectedError) ...