Add banSplitPackages rule: module-path split-package detection

[ascheman]

Implements the banSplitPackages rule proposed in #997 — the follow-up announced in #996.

Important

Stacked on #996. The first four commits are #996 (module-info reader + three rules); only the top three commits (feat / test / docs for banSplitPackages) are new here. Once #996 merges I will rebase onto master and the diff collapses to just the new rule. Draft until then.

Rule

A package must belong to exactly one Java module — two modules on the module path containing the same package fail resolution (java.lang.module.ResolutionException), typically at packaging, jlink, or first boot, with a symptom-not-cause message. And if the offending module is not even requiresd, the resolver never pulls it in: the build stays green while a type or endpoint is silently absent at runtime.

• Project packages come from walking the output directory, not the compiled descriptor — ModulePackages is only finalized at packaging time, and offending classes are frequently added after compile (code generation, copied resources). Both the classic layout and the Maven 4 module source hierarchy are supported (same moduleOutputs() discovery as Add Java module-info rules: requireExplicitModules, requireMinimalExports, banUnjustifiedOpens #996).
• Dependency packages are read through java.lang.module.ModuleFinder (reflectively — same Java 8 baseline rationale as the reader in Add Java module-info rules: requireExplicitModules, requireMinimalExports, banUnjustifiedOpens #996), which derives automatic-module names and reports complete package sets; artifacts the finder cannot model fall back to a plain class-file scan.
• The rule intersects against the full declared-dependency set, deliberately not only the requiresd modules — this is what catches the silent variant.
• Severity model: overlap between two artifacts that both end up on the module path → error. An automatic module counts as "on the module path" only when a project module actually requires its derived name. Overlaps involving a classpath-only artifact are legal today and reported at <classpathSeverity> (default warn) as a modularization hazard.
• Configuration: classpathSeverity (warn/error/ignore), allowedSplitPackages, ignoredModules, ignoredArtifacts, message.
• Non-goal: a provider that is not a declared Maven dependency (pure runtime) is out of scope. The rule is a safety net, not a fix — the durable cure is placing generated/copied classes in the module that owns their package.

Design note: dependency resolution

ResolverUtil is widened to public: the enforce mojo declares only requiresDependencyCollection, so artifact files are not resolved by default; the rule resolves them explicitly — the same approach enforceBytecodeVersion already uses.

Tests

• 15 unit tests (Java 9+ gated; ASM fixtures in test scope only, extended with a JAR fixture writer for explicit/automatic/plain dependency artifacts).
• Four ITs under maven-enforcer-plugin/src/it/projects/: a classic two-artifact reactor failing on the silent variant, a clean pass, a classpath-overlap warn case (build succeeds, warning names the automatic module), and a Maven 4 module-source-hierarchy fail case (gated 4.0.0-rc-5+ / JDK 17+).
• Full mvn clean verify -P run-its green on Maven 3.10.0-rc-1 (158 ITs passed); the four new ITs additionally verified on Maven 4.0.0-rc-5.

---

• Your pull request should address just one issue, without pulling in other changes.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied.
• Run mvn verify to make sure basic checks pass.
• You have run the integration tests successfully (mvn -Prun-its verify).
• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

(Replaces #999, which GitHub auto-closed when the head branch was renamed to feature/997-ban-split-packages.)

[scordio]

Successfully tested locally on the AssertJ build, see output logs at assertj/assertj#4331 (comment).