LL: add class InvalidEncodingException and flag VALIDATE_UTF8_ENCODING

[LLyaudet]

to call validateUTF8Encoding() function.

[LLyaudet]

See #52

[LLyaudet]

This is a first draft.
Please let me know if the information given in the thrown exceptions is OK for you.
If you have any other remarks, I'll be happy to improve the code.
Currently, I think I could also add some testing,
but we need to be OK on the information given in the thrown exceptions first.

[Seldaek]

I think it looks ok (the exception message). Having some unit tests definitely would help tho.

[stof]

should be private IMO

[LLyaudet]

Yep, probably no further specialization of this exception will be done in the code.
Since the PR is already merged, I will prepare another PR to address your remarks that are not already dealed with.

[stof]

even if specialization is done, the child class can use the getter if it needs to read it.

Btw, I'm not even sure whether those details are useful. I fail to see what they bring compared to the message.

[LLyaudet]

even if specialization is done, the child class can use the getter if it needs to read it.

Ok, but you can't overwrite the PHPDoc in that case, if you want distinct keys in the details array after specialization.

Btw, I'm not even sure whether those details are useful. I fail to see what they bring compared to the message.

Noob ;). You always need the strongly typed data instead of a hotchpotch string if you want to do further error handling of the exception and some automatized recovery after failure instead of just printing the message of the exception :).

[stof]

Ok, but you can't overwrite the PHPDoc in that case, if you want distinct keys in the details array after specialization.

Changing the type of a property in a child class does not respect variance rules anyway.
And I don't see the use case anyway for specializing the class: the library will not use your special child class as it won't know about it.

[LLyaudet]

Then you need to talk with @Seldaek about variance rules, because currently it already overrides ParsingException:

class ParsingException extends \Exception
{
    /**
     * @var array{text?: string, token?: string|int, line?: int, loc?: array{first_line: int, first_column: int, last_line: int, last_column: int}, expected?: string[]}
     */
    protected $details;

I assumed array type hint was enough.
Feel free to propose a PR for "the details" ;).
I will mess up with the tests in the meantime :).