New rules: enforce Java Module System descriptor policy #995

Description

Following mojohaus/extra-enforcer-rules#361, @slawekjaranowski suggested these rules would fit the standard Enforcer plugin rather than extra-enforcer-rules. Opening here as proposed.

Use case

Projects adopting module-info.java want to keep their descriptors clean, but there is no built-in way to enforce module policy in the build — today it is review-by-eyeball or ad-hoc scripts.

Proposed rules

• requireExplicitModules — fail if the project artifact and/or its production dependencies are automatic modules (Automatic-Module-Name) or unnamed (no module-info). Optional allowlist.
• banUnjustifiedOpens — fail on opens directives in the project's module-info that are not in a configured allowlist (default: none allowed).
• requireMinimalExports — fail on exported packages matching a configurable pattern (default **.internal.**, **.impl.**), i.e. exporting non-API packages.

Implementation notes

• Reads module-info.class directly from the class-file bytes (JVMS §4.7.25) via a small dependency-free reader, so it works on the plugin's Java baseline without ASM or the java.lang.module API. A working prototype (reader + unit tests) already exists from the extra-enforcer-rules exploration and can be moved here.
• Rules target the reactor module's own compiled module-info.class (post-compile phase) plus dependency jars for the automatic/unnamed check.
• Full unit tests + integration tests + site documentation, following the existing rule style.

Happy to open the PR. cc @slawekjaranowski

Refs: mojohaus/extra-enforcer-rules#361