Implement module imports in Java 25 parser

[Laurens-W]

What's changed?

Add support for module imports in the Java 25 parser

What's your motivation?

Making the parser idempotent

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[Laurens-W]

We extend the grammar of import declarations ([JLS §7.5](https://docs.oracle.com/javase/specs/jls/se23/html/jls-7.html#jls-7.5)) to include import module clauses:

ImportDeclaration:
  SingleTypeImportDeclaration
  TypeImportOnDemandDeclaration
  SingleStaticImportDeclaration
  StaticImportOnDemandDeclaration
  ModuleImportDeclaration

ModuleImportDeclaration:
  import module ModuleName;

https://openjdk.org/jeps/511

This concerns me a little, as that means ImportTree (input of visitImport in our parser) can now be two things; JCImport or JCModuleImport.
If we introduce a new LST element (J.ModuleImport) to mimic this, that means we need to add commonality (Import interface, AST defines boolean isStatic(); boolean isModule(); and Tree getQualifiedIdentifier(); the latter i've shortened to Qualid like we do in other places) between that and J.Import and do a massive refactoring of any places using J.Import, as a CompilationUnit will then return the interface and not the implementation.

On the other hand we can choose to add it to J.Import (module like statik which is modeled in the AST somewhat like that, handle the prefix of the keyword etc) but this leaves surface for issues later on

[timtebeek]

As a quick thought: once we have merged the parser support, we'll likely also want to adapt the style detection to figure out at which point to switch from explicit imports to module imports, much like we do for wildcard imports. That tally can then factor into OrderImports to adopt module imports there.

[knutwannheden]

I think at least the getter here also needs to be @Nullable.