[SPARK-61280][PYTHON][TEST] Start the in-process UDF probe JVMs with Spark's module options

### What changes were proposed in this pull request?

Four tests in `python/pyspark/sql/tests/test_inprocess_udf.py` start a fresh JVM with a hand-written `java` command line: `test_missing_cdi_dependency_fails_plugin_startup`, `test_missing_jep_has_an_initialization_hint`, `test_fresh_jvm_retries_configuration_without_spark_home` and `test_failed_bootstrap_preserves_message_and_freezes_site_packages`. Two of them pass a hand-picked subset of Spark's JVM options (two `--add-opens` and `-Dio.netty.tryReflectionSetAccessible=true`), and the other two pass none.

This PR adds a helper, `_java_command(jvm, java_home)`, which returns this test's `java` followed by `JavaModuleOptions.defaultModuleOptionArray()`, the options Spark's own launcher passes to every JVM it starts. All four probes now build their command line from it, so a probe JVM starts the way Spark's JVMs do on every Java version.

### Why are the changes needed?

On Java 25, `test_missing_jep_has_an_initialization_hint` and `test_fresh_jvm_retries_configuration_without_spark_home` fail. The fresh JVM each one starts exits 1 with:

```
java.lang.ClassCastException: class io.netty.buffer.PooledDirectByteBuf cannot be cast to class io.netty.buffer.PooledUnsafeDirectByteBuf
```

On Java 25+, Netty 4.2 turns off its use of `Unsafe` unless the JVM runs with `--sun-misc-unsafe-memory-access=allow`. Arrow's `PooledByteBufAllocatorL$InnerAllocator.newDirectBufferL` always casts the buffer Netty returns to `PooledUnsafeDirectByteBuf`, so without `Unsafe` the first Arrow allocation throws. Both probes allocate one: one through `InProcessArrowBridge.verifyDependencies`, the other through `InterpreterSession.register`.

Spark's own JVMs get that option from `JavaModuleOptions`, which added it in SPARK-56955. The probes copied part of that list by hand before it was added, so they never got it. Taking the list itself fixes the failure and keeps the probes in step with the next option Spark adds. It also gives the probes that load jep's native library `--enable-native-access=ALL-UNNAMED`, which avoids the restricted-method warning on Java 24+. And the two probes that pass a bare `java` today, because they fail before Arrow allocates, get the same options, so they do not break the same way if that code path changes.

CI has not caught it because the tests are skipped wherever jep is missing. The Java 25 build uses the `python-311` image, which has no jep. A Java 25 build on the `python-312` image, which installs jep, fails both tests. Running these tests on Java 25 with jep in CI would be a separate change to the test images.

### Does this PR introduce _any_ user-facing change?

No. Test code only.

### How was this patch tested?

- Reproduced the failure outside Spark with a one-file Java program that calls `new RootAllocator().buffer(64)` against the Arrow 19.0.0 and Netty 4.2.20 jars Spark uses:
  - On JDK 25 with the probes' old options, it throws the same `ClassCastException` and exits 1.
  - On JDK 25 with `--sun-misc-unsafe-memory-access=allow` added, which `JavaModuleOptions` includes, the buffer is allocated and it exits 0.
  - On JDK 21 it exits 0 either way. `JavaModuleOptions` starts with `-XX:+IgnoreUnrecognizedVMOptions`, so Java 21 accepts the newer options, as it does for Spark's own JVMs.
- The two tests fail in a Java 25 build that installs jep (the `python-312` image).
- `ruff check` and `ruff format --check` pass on the file.

### Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Opus 5.5)

Closes #60257 from MaxGekk/SPARK-61280-inprocess-unsafe.

Lead-authored-by: Max Gekk <max.gekk@gmail.com>
Co-authored-by: t <t@example.com>
Signed-off-by: Max Gekk <max.gekk@gmail.com>


skip-checks: true