feat(#20): add mystery-object lint

[VasilevNStas]

fix #20

What

A new Java-based lint mystery-object is added. It is registered in
MonoLints together with the other hand-coded lints (ascii-only,
reserved-name). The full set of artifacts:

• src/main/java/org/eolang/lints/LtMystery.java — the lint implementation
• src/main/resources/org/eolang/motives/names/mystery-object.md — the motive
• src/test/java/org/eolang/lints/LtMysteryTest.java — unit tests
• src/test/resources/org/eolang/lints/*.eo — EO fixtures used by the tests

Why

Consider this program:

[] > foo
  bar 42 > x

The object bar is neither defined in the program, nor imported via
+alias, nor one of the org.eolang objects. Such a call is almost always
a typo in the object name. Still, the parser happily compiles it into a
bare Φ.bar reference and nobody complains. The program reaches the
compile/run pipeline and fails there with an obscure error, far away from
the actual mistake.

This lint detects exactly that situation and reports it as an error
right at the source line.

How it works

The parser resolves any object application into a base attribute. There
are three interesting shapes:

• Φ.org.eolang.io.stdout — a qualified path (result of +alias or a
  fully-qualified name). Always legitimate, never reported.
• Φ.number, Φ.bytes, etc. — references to prime org.eolang objects.
  Legitimate, but only when the name is really one of the reserved top-level
  objects of the home repository.
• Φ.bar — a bare single-name reference. This is the suspicious case.

The lint walks every //o[@base] element and applies the simple-name
pattern ^Φ\.[a-z][a-z0-9_-]*$. Any element that matches must prove its
right to exist:

1. The name is declared somewhere in the current program, i.e. there is a
   //o[@name='bar'] node in the same XMIR — a legitimate local object, or
2. The name is present in ReservedNames — the CSV of the org.eolang
   top-level objects, generated from the home repository on the reserved
   build profile.

Everything else is a mystery object and gets an error defect.

Aliased objects need no special handling: the parser resolves an alias into
a dotted path (Φ.org.eolang.io.stdout), which never matches the simple
one-word pattern, so they are excluded by construction.

Why not an XSL lint

The decision on "is NAME a legitimate org.eolang object" depends on the
runtime list from the home repository (ReservedNames, backed by
reserved.csv generated on the reserved Maven profile). XSL transforms
cannot read that runtime data, while a Java lint can — this is the same
reason the existing reserved-name lint is implemented in Java.

Robustness against a missing reserved list

reserved.csv exists only when the reserved profile is active (CI does
this in a dedicated reserved.yml workflow). In the default mvn test
run the map is empty. The lint handles this gracefully: with an empty list
it returns no defects. The full behavior matrix is exercised in the
@Tag("reserved") integration test (scansMysteryFromHome), which runs
against the real home data in CI.

Tests

• catchesMysteryObject — bar with no definition is caught
• reportsCorrectMessageForMysteryObject — message names the object
• allowsDeclaredObject — local bar declaration is fine
• allowsAliasedObject — +alias import is fine
• allowsCanonicalObject — org.eolang literal (42) is fine
• allowsAllObjectsDeclaredInline — all inline declarations are fine
• scansMysteryFromHome (@Tag("reserved")) — integration against the
  real reserved list from home

Both mvn test (592 tests) and mvn clean install -Pqulice pass.

[VasilevNStas]

@volodya-lombrozo plz review this PR

[VasilevNStas]

@volodya-lombrozo plz re-review
I`m fixed it