YAML fixtures limited to XSL-based lints, leading to unnecessary JUnit classes for Java-implemented lints

I cannot test Java-implemented lints (LtAsciiOnly, LtReservedName, LtIncorrectUnlint, and the new LtSyntaxVersion) the same declarative way as XSL lints, because packs/single/*.yaml only understands a sheets: key listing XSL stylesheet paths, run through Xsline in LtByXslTest.testsAllLintsByEo. There is no equivalent for a Lint implemented in plain Java, so every hand-written lint needs its own bespoke JUnit test class instead of a short input/asserts pack.

Proposed Solution

Let a pack yaml reference a lint by name instead of only by XSL sheet path, e.g.:

sheets:
  - /org/eolang/lints/metas/incorrect-version.xsl

vs.

lint: syntax-version

LtByXslTest (or a sibling test) could resolve lint: against the same lint registry MonoLints/PkMono already build, run Lint.defects(XML) directly, and reuse the existing DefectsMatcher/XtDefects assertion machinery already in place for the sheets: path.

This would let Java lints share the same lightweight, declarative test format as XSL lints, instead of requiring a new Lt*Test.java class (with EoProgram/InputOf boilerplate) for each one.

Relevant classes to investigate: LtByXslTest, XtYaml, XtDefects, MonoLints, PkMono.

Start with LtByXslTest and the handling of packs/single/*.yaml, then inspect XtYaml, XtDefects, MonoLints, and PkMono to understand how existing sheets entries resolve and assert defects. Done means a pack can identify a Java lint by name and reuse the existing defect assertions without a bespoke JUnit class.