Support Java 25 module import declarations (JEP 511)

What problem are you trying to solve?

import module java.base; (JEP 511) isn't handled by the parser. ReloadableJava25ParserVisitor.visitImport only looks at isStatic(), never ImportTree.isModule(), so the module keyword is left unconsumed and the source cursor desyncs. The result isn't a clean failure but corrupted output:

-import module java.base;
+import javale java.base;

Any project using module imports therefore fails the print idempotency check.

Prior work

• #5993 was closed with the JEP 511 box unchecked.

• #5997 implemented this as a module flag on J.Import (next to statik), and was closed unmerged:

  I don't approve of the approach. The JLS and compiler itself differentiate between module imports and non-imports, and I think it will add complexity to every import-related features if J.Import represents both. Closing and will redo at a later time.

  — @jkschneider, https://github.com/openrewrite/rewrite/pull/5997#issuecomment-3835776840

• The review on that PR had already framed the choice. @Laurens-W noted that ImportTree can now be either a JCImport or a JCModuleImport, and laid out the two options: a new J.ModuleImport plus a shared Import interface (isStatic() / isModule() / getQualid()), which makes CompilationUnit return the interface rather than the implementation and requires refactoring the existing J.Import usages; or the module flag, which "leaves surface for issues later on".

• @sambsnyd noted that a model change here needs a SaaS deployment queued after merge.

• The parser and printer changes in #5997 remain a useful reference however the LST ends up being modelled.

Start with ReloadableJava25ParserVisitor.visitImport and the parser/printer changes in #5997. Read the prior discussion of J.Import versus a separate module-import model, including ImportTree's JCImport and JCModuleImport forms. Done means import module java.base; parses without cursor desynchronization and passes the print idempotency check.