Bumps `asm.version` from 9.8 to 9.9.

Updates `org.ow2.asm:asm` from 9.8 to 9.9

Updates `org.ow2.asm:asm-commons` from 9.8 to 9.9

---
updated-dependencies:
- dependency-name: org.ow2.asm:asm
  dependency-version: '9.9'
  dependency-type: direct:production
  update-type: version-update:semver-minor
- dependency-name: org.ow2.asm:asm-commons
  dependency-version: '9.9'
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>

* #426 Add JPMS module support with ServiceLoader

**Note:** This is not a complete solution as handling of JDK 8
compatibility is outstanding. Currently, the fix would break
usage of JDK 8.

Enable `exec:java`-goal to execute Java applications using the Java
Platform Module System (JPMS) with proper ServiceLoader support.

Changes:
- Split execution logic into classpath and module-path modes
- Detect module syntax (module/class) in mainClass parameter
- Create ModuleLayer with resolveAndBind() to include service providers
- Use ModuleLayer.Controller to open packages for reflective access
- Set thread context classloader to module's classloader

The plugin now properly handles:
- Module-path execution when `mainClass` uses "module/class" syntax
- ServiceLoader provider discovery and binding in modular applications
- Reflective access to main methods in unexported packages
- Mixed module and classpath dependencies

Integration test mexec-gh-426 validates the ServiceLoader functionality
with a multi-module JPMS application (contract, provider, consumer).

Technical implementation:
- Use Configuration.resolveAndBind() instead of resolve() to include
  service providers declared with "uses" in module-info
- Obtain ModuleLayer.Controller to programmatically open packages via
  addOpens() for reflective main method invocation
- Load classes through the module layer's ClassLoader to maintain
  proper module isolation and visibility

The fix was created in the course of support-and-care/maven-support-and-care#138.

* #426 Fix JSR-512 main method detection

This commit fixes two issues that caused build failures in GitHub:

1. JSR-512 Main Method Detection

Problem: Tests failed with error:
"The specified mainClass doesn't contain a main method with
appropriate signature"

JSR-512 (Java 21+) allows flexible main methods that can be
non-public and instance methods. The original code used
getMethod() which only finds PUBLIC methods, causing it to
fail when searching for package-private main methods.

Solution:
- Changed from getMethod() to getDeclaredMethod() for JSR-512
- Added setAccessible(true) for non-public method invocation
- Created findMethod() helper that searches class hierarchy
- Validates return type is void (JSR-512 requirement)
- Maintains correct priority order:
  1. static void main(String[]) - traditional
  2. static void main() - JSR-512 static no-args
  3. void main(String[]) - JSR-512 instance with args
  4. void main() - JSR-512 instance no-args

2. SystemExitException Logging

Problem: Integration tests expected [ERROR] log prefix for
SystemExitException but it was missing.

When SystemExitException was thrown during method invocation,
it got wrapped in InvocationTargetException and bypassed the
logging code.

Solution:
- Added special handling in InvocationTargetException catch
- Detects SystemExitException in the cause chain
- Logs with appropriate level (ERROR for non-zero exit codes)
- Re-throws the exception to maintain expected behavior

* #426 Create Multi-Release Jar

* #426 Move common ExecJava code to base class

* #494 Find classic main method even if private