New rules: enforce Java Module System descriptor policy

## 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_