Handle sub errors (base field is defined here, defined in this class)

[kLabz]

Groups "Base field is defined here" and "Defined in this class" errors with their parent error.
Edit: also groups other "multi-error" errors like overload resolution failures, unification failures for fields from interfaces, etc.

Has no effect when not using friendly-errors-webpack-plugin.

Before:

After:

Overload resolution failure example:
before / after

Note: errors were already grouped by location, so the overload resolution failure was already short but not easy to read.

[kLabz]

Whoops, typo. Do not merge yet.

[kLabz]

Corrected + added more sub errors

[kLabz]

Found a lot more errors to handle, working on it.

[kLabz]

Should be ready, I did not find any other sub errrors in haxe compiler sources (there could be more that I missed, with a different code style, but they could be handled later if needed).

Seems tedious to add real-world tests for that: minimal sources to produce the haxe errors, get haxe's stderr when compiling them, extracts webpack errors from that, call errorFormatter.format() and check the result (or maybe just the resulting errors array). I don't have the courage to do that atm.

[elsassph]

Generally that seem quite risky to rely on exact wording - now that said, if we go this route, it looks like error.message is usually clearly enough a sub error, even without checking previous.message (excepted that it is defined).

[kLabz]

I used exact wording only when the error messages are hardcoded in the compiler, and followed the rules there for sub errors.

I'd prefer some errors not to be grouped any more after a change in the compiler than errors being grouped when they are not related (could happen when a macro generates an error with a message similar to one of the "multiple-errors" generated by the compiler).

[elsassph]

Looks good