Merge `log4j-*-java9` modules into `log4j-api` and `log4j-core`

The `log4j-api-java9` and `log4j-core-java9` modules are a relict from
an era where multi-release JAR content could not be produced by the
consuming Maven module itself.  Each compiled a handful of Java 9
sources (padded with stub classes to satisfy the compiler), zipped them
in a `classes/META-INF/versions/9` layout and had the consumer unpack
the zip into `target` at `prepare-package`.

Compile the Java 9 sources directly in `log4j-api` and `log4j-core`
instead, using a second `maven-compiler-plugin` execution over
`src/main/java9` with `<release>9</release>` and
`<multiReleaseOutput>true</multiReleaseOutput>`.  The execution stays
bound to `prepare-package` so that `bnd-maven-plugin` (at
`process-classes`) never sees the versioned classes, as before; the
`Multi-Release: true` manifest entry keeps coming from the
`bnd-multi-release` property.  The published artifacts are unchanged:
the versioned class list and bytecode are identical, and the stubs
are no longer needed since the real classes are on the compile
classpath.

The Java 9 `StackLocator` tests move to `log4j-api-test` as a
`maven-failsafe-plugin` integration test running against the packaged
multi-release JAR, with a guard assertion that the
`META-INF/versions/9` variant is actually loaded.  The two
`getCurrentStackTrace` tests only passed against the old module's
stubbed `PrivateSecurityManagerStackTraceUtil` and are dropped: against
the real classes they exercise the `SecurityManager` path, which
`StackLocatorUtilTest` already covers.  The Java 9 `ProcessIdUtilTest`
was assertion-identical to the existing one in `log4j-api-test`.

Assisted-By: Claude Fable 5 <noreply@anthropic.com>