feat(#3742): Split ParsingErrors on Two Separate Classes

[volodya-lombrozo]

In this PR I:

1. Createad a separate package errors for all error handlers and realted classes.
2. Split ParsingErrors on EoParserErrors and ParsingErrors
3. Added supplementary classes like Lines and ErrorDirectives to share common logic across all the new classes.

When this PR seems having a lot of lines, it just moves some parts of the code across the codebase.

Closes: #3742.

[volodya-lombrozo]

@yegor256 Could you review these changes, please?

[yegor256]

@volodya-lombrozo looks interesting, a few comment above

[volodya-lombrozo]

@yegor256 Could you have a look one more time, please?

[yegor256]

@volodya-lombrozo the naming of classes is rather confusing here: they look almost the same. Why don't you use the names suggested in the puzzle: ParserErrors and LexerErrors?

[volodya-lombrozo]

@volodya-lombrozo the naming of classes is rather confusing here: they look almost the same. Why don't you use the names suggested in the puzzle: ParserErrors and LexerErrors?

@yegor256 I agree that the naming here is confusing. Let me try to explain. Before that PR, we had only one error listener: ParsingErrors, and that's all. I thought it would be fine to split it into two separate parts—LexerErrors and ParserErrors. When I started implementing this PR, I noticed that you were using the same ParsingErrors for both EoSyntax and PhiSyntax, which works fine until we implement language-specific error messages. So, instead of LexerErrors and ParserErrors, I would have to create EoLexerErrors, EoParserErrors, PhiLexerErrors, and PhiParserErrors. That would result in too many classes (and I wouldn't be able to sell that idea to you! 😊). As a result, I decided to leave ParsingErrors as it is and simply add one more class: DrEoParserErrors, specifically for EO errors. Please feel free to ask questions if anything is unclear.

[volodya-lombrozo]

@yegor256 Recent changes:

1. Renamed ParsingErrors -> GeneralErrors (?)
2. Removed package
3. GeneralErrors and EoParserErrors don't implement Iterable<Directive> anymore. They create directives through the directive() method instead.

[yegor256]

@volodya-lombrozo it's much better now! please, see my comments above

[volodya-lombrozo]

@yegor256 Please review these changes: fbbaa29. I can accommodate your suggestions in this manner (it's the only way). If you don't like the solution, we can revert them.

[yegor256]

@volodya-lombrozo can't you simply calculate the size of Iterable with the help of LengthOf from Cactoos? This Errors class looks redundant here. It only complicates the design adding no value: the user already knows what is "iterable", making him learn a new paradigm "errors" is a burden for him.

[volodya-lombrozo]

@yegor256 Sure, please, check this one: d4764a6
I've done it. However, I don't prefer such a solution because we hide an abstraction, that we actually have. Although, I should admit, that we have less code now.

[yegor256]

LGTM

[yegor256]

@volodya-lombrozo thanks!