Preserve stack capture with a StackWalker opt-out

Surefire 3.6.0 switched Java 9+ stack capture to StackWalker. A downstream Windows x64 and JDK 25 workload using FFM callbacks from native background threads then reported deterministic forked-JVM termination. Its existing workaround set stackTraceMaxFrames to zero, which also removed stack diagnostics.

Adds surefire.stackTrace.disableStackWalker as an opt-out evaluated during stack-provider configuration. When enabled, Surefire uses its existing Thread.getStackTrace() path; StackWalker remains the default, Java 8 behavior is unchanged, and a SecurityException while reading the property fails back to the default path.

• Provides a bounded compatibility escape hatch for affected test JVMs while preserving useful stack traces.
• Keeps the lower-allocation StackWalker implementation as the default for unaffected Java 9+ builds.
• Documents how forked tests pass the property through argLine, including projects that already carry other JVM options.
• Adds focused regression coverage for both the opt-out and unchanged default behavior.
• Does not claim to fix the underlying JVM interaction; the merged change supplies a Surefire-side workaround for a failure maintainers considered likely rooted in the JDK.

• The authored change passed focused tests on JDK 8, a local Maven clean install on JDK 21, and a Linux arm64 JDK 25 clean install.
• The pull request's hosted Verify matrix passed across Linux, Windows, and macOS on JDK 8, 11, 17, and 21; the unrelated label-automation check failed because a label still needed assignment.
• Apache Maven Surefire maintainer Olivier Lamy merged the authored commit and closed GH-3459. Full reproduction of the downstream Windows x64 and JDK 25 crash with the opt-out was not claimed as completed.