[#60] Publish a stable JPMS automatic module name

[peter-lawrey]

What changed

• Publishes Automatic-Module-Name: net.openhft.hashing in the packaged bundle.
• Adds an integration test that opens the actual packaged JAR during Maven verify.

Why

This is Stage 1 of issue #60. It establishes the permanent consumer-facing module name with minimal compatibility risk while retaining the Java 8 release build. The same name is used by the explicit descriptor proposed in #107, so consumers will not need to change their requires net.openhft.hashing declaration later.

This PR complements #107; it is not a replacement for that contribution.

Scope and limitations

This stage provides:

• a stable automatic module name;
• use as an automatic module on Java 9+;
• a non-breaking path to an explicit descriptor.

It does not yet provide:

• a real module-info.class;
• strong encapsulation or an explicit requires jdk.unsupported;
• jlink support;
• complete module-path runtime hardening.

Those belong to the repository-owned continuation of #107 and the final hardening stage.

Validation

• JDK 8: mvn -B clean verify — 14,901 unit tests, 12 skips; packaged-JAR integration test 1/1.
• The exact JDK 8-built JAR ran a public API smoke test on Java 8 and Java 25.
• Java 25 identified the JDK 8-built JAR as automatic module net.openhft.hashing.
• JDK 25: mvn -o -B clean verify — both configured unit-test executions and packaged-JAR integration test passed.
• TeamCity passed Java 8, 11, 17, 21, 25, 26, 27, Zing 8/11, and ARM on this source head.
• git diff --check passed.
• Reachable branch history contains no Claude or Anthropic references.

The legacy GitHub workflow currently fails before checkout because it uses retired actions/cache@v1. Its separate workflow/Sonar maintenance is intentionally outside this PR.

Tracking

Part of #60.
Stage 1 of the JPMS migration.

[bmarwell]

I have no clue what you mean by:

                      without shipping a module descriptor, keeping the Java 8 build intact.

In my PR, it's not broken! It just doesn't create a module descriptor on the Java 8 build, so the Java 9+ build would need to be shipped.

This PR doesn't create a proper module descriptor and doesn't add a test whether module loading actually works. An automatic module name will gain you nothing, really (except you can rename the jar file locally, which no one ever should do). So, still no jlink, modular distribution for jreleaser, etc.

It's not wrong or bad to do it this way, it just doesn't solve the majority of the problems.

dirty

... I hope you just mean "not rebased"?

[peter-lawrey]

@bmarwell I haven't reviewed this draft yet. The plan was to produce a minimal solutions to a problems that has been open for 3+ years. I couldn't say that anything you have done is wrong, though it's more involved, possibly a more comprehensive solution.

[peter-lawrey]

@bmarwell The unmergable comment was due to a restricted main ea branch. The merge needs to be with develop