Add error recovery

[NebelNidas]

Parsers no longer fail when encountering invalid entries. Depending on the situation, the issue is either

• logged as info when entries are not 100% conformant but data isn't affected in any way,
• logged as a warning when non-vital mapping data is missing, or
• logged as an error when elements had to be skipped entirely.

These logs are written to an ErrorSink, which consumers can either implement themselves for custom behavior, or simply use the default implementation via the noOp() factory method. I also added the ErrorCollector interface, which is an extension of ErrorSink, keeping track of all the occurred errors.
To keep compatibility with older versions, by default a ThrowingErrorSink is used, which throws an IOException upon receiving an error of a certain severity, WARNING by default to roughly mirror legacy behavior.

[modmuss50]

Why deprecate this, I think by default it should fail when it reads a malformed mapping file?

[NebelNidas]

To not have a dozen different overloads. You can use the ErrorSink#noOp() or ErrorSink#throwingOnSeverity(...) factory methods, just like you'd use ProgressListener.none() in Enigma

[liach]

Is ther why new ThrowingErrorSink(Severity.WARNING) is a bad default severity? Overloads is like a way to imply default arguments.

[NebelNidas]

It hinders readability and is a pain to maintain. We already have up to five overloads per mapping reader, imagine we were to add an additional argument in the future, it would double the count again. MappingReader#read already has eight overloads, which I'm pretty sure starts getting confusing for consumers.

At least the latter one would be remedied by #56, which gets rid of some of the overloads by removing implicit format detection.

[liach]

If we have too many optional arguments, we might just use builders.

[modmuss50]

Could the line number and column be optionally passed though? I see a lot of them include it in the message but might be nice to access this data programmatically?