bug(tool): resolve the stale -Dlanguage=Rust Java target stub

[tinovyatkin]

Summary

The checked-in Java ANTLR target advertises a normal -Dlanguage=Rust target,
but it is currently unusable:

• Rust.stg
  defines only codeFileExtension();
• RustTarget.java
  uses an obsolete Target API and does not compile against the repository's
  pinned ANTLR 4.13.2 tool;
• tool/README.md
  describes the target as an implementation in progress while the production
  generator is antlr4-rust-gen.

The repository should not retain a discoverable half-target which neither
builds against the pinned tool nor emits recognizers. Either make the Java
target a tested supported path, or remove/disable it and state explicitly that
antlr4-rust-gen is the sole Rust generator.

Reproduction

With the pinned jar from the repository setup instructions:

javac \
  -cp target/antlr-cleanroom/tools/antlr-4.13.2-complete.jar \
  tool/src/org/antlr/v4/codegen/target/RustTarget.java

Observed on main@5caa7d3e:

RustTarget is not abstract and does not override abstract method getReservedWords()
constructor Target cannot be applied to given types
getBadWords() ... does not override or implement a method from a supertype
encodeIntAsCharEscape(int) ... does not override or implement a method from a supertype

The class uses super(gen, "Rust"), boolean header file-name methods,
getBadWords, and encodeIntAsCharEscape; ANTLR 4.13.2 expects the current
Target(CodeGenerator), SourceType methods, getReservedWords, and target
escape-map surface.

Even after updating the Java class, the template group lacks ParserFile,
LexerFile, rule, decision, listener, visitor, action, and predicate templates,
so normal ANTLR code generation cannot complete.

Goal

Resolve the product contract explicitly.

Supported-target outcome

If -Dlanguage=Rust is intended to be supported:

• port RustTarget.java to the pinned ANTLR API;
• implement a complete template group that emits the current runtime's
  generated-code contract;
• keep identifiers, actions, contexts, listeners/visitors, packed ATN data,
  lexer DFA data, diagnostics, and codegen API checks behaviorally aligned with
  antlr4-rust-gen;
• add Java-tool integration tests and generated Rust compile/run tests;
• define how releases keep the Java target and Rust-native generator from
  diverging.

Rust-native-only outcome

If antlr4-rust-gen remains the sole production generator:

• remove the stale Java target/resource, or replace it with an explicit,
  targeted unsupported diagnostic;
• remove claims that the Java target is merely awaiting template expansion;
• document the supported invocation and why -Dlanguage=Rust is not provided;
• ensure packaging cannot make ANTLR appear to discover a nonfunctional target.

Given #141's single authoritative .g4 frontend and its explicit non-goal of
reimplementing target StringTemplates, the Rust-native-only outcome is likely
the smaller maintenance contract unless official ANTLR integration is now a
project goal.

Acceptance criteria

• The repository chooses and documents one of the two outcomes above.
• No checked-in RustTarget claims compatibility with an ANTLR API it does
  not compile against.
• java ... -Dlanguage=Rust either produces compiling, tested Rust or fails
  immediately with an intentional actionable diagnostic.
• The supported generator path is unambiguous in the root and tool
  documentation.
• If retained, Java target compatibility is tested against the exact pinned
  ANTLR version.
• If retained, generated-source/runtime compatibility uses the same API
  revision policy as antlr4-rust-gen.

Related

• Support strategy for target-language semantic predicates and actions #9 listed a full Rust ANTLR target as the highest-scope semantic solution.
• codegen: make .g4 the sole production input and remove the legacy .interp path #141 made the Rust-native .g4 frontend the sole production input and
  explicitly excluded unrelated StringTemplate emitters.

Non-goals

• Copying the sdf-labs/antlr4 template or its arena/runtime ABI.
• Maintaining two production generators without automated behavioral parity.