Switch native smoke tests to the smoke-test plugin

[bric3]

What Does This Do

Migrates dd-smoke-tests/spring-boot-3.0-native and dd-smoke-tests/quarkus-native from raw Exec against $rootDir/gradlew to the dd-trace-java.smoke-test-app plugin (added in #11405).

The nested native builds now run through the Gradle Tooling API on a pinned Gradle 8.14.5.

To support the native flavor, the plugin and testJvmConstraints gain a few things:

• SmokeTestAppExtension.javaLauncher — pin the nested daemon JDK explicitly when an inner plugin chain requires it.
• NestedGradleBuild.environment — extra env vars merged on top of the outer process environment, used to forward GRAALVM_HOME etc. to the nested daemon.
• NestedGradleBuild is now @CacheableTask, so the expensive native-image output is reusable across CI smoke-test slots — the prior Exec-based wiring set outputs.cacheIf { true } to opt in explicitly.
• testJvmConstraints.nativeImageCapable allows to ensure the testJvm provides native-image.
• SmokeTestAppExtension.projectJar(name, project, configuration) overload, so consumers can target a non-default variant like the agent's shadow configuration.

Motivation

Same root cause as #11407: as soon as the root project moves to Gradle 9, the Spring Boot Gradle plugin pre-3.5 inside the nested application/ builds breaks (Configuration.getUploadTaskName() is gone). While running the nested project on Gradle 8.14.5 works.

The native modules also carried two extra hazards worth fixing in the same pass:

• Cross-project task reach-through (project(':dd-java-agent').tasks.shadowJar.archiveFile.get())
  It is evaluated eagerly at configuration time, and might break under Gradle 9's stricter project isolation. It has been replaced with consumer-configuration-based wiring through projectJar(...).
• Daemon JDK / native-image plugin compat
  The old code forked gradlew directly, which on the GraalVM 21 slot meant running Gradle 9 (post-bump) on a JDK 21 GraalVM. This is now decoupled via the smoke test plugin.

For Spring Boot 3.0 specifically, the inner app's compileJava now sets options.release = 17 so it emits major-61 class files regardless of the daemon JDK ; indeed Spring Boot 3.0's bundled ASM 9.4 can't read major-65 (Java 21) classes, so without this the inner :resolveMainClassName task fails with Unsupported class file major version 65 (observed in CI on both graalvm17 and graalvm21 slots).

Additional Notes

• Follow-up of Switch spring-boot-2.7-webflux to the smoke-test plugin #11407 (spring-boot-2.7-webflux migration), same pattern applied to the two native modules.
• Part of the Gradle 9 readiness work tracked in WIP / DRAFT gradle 9.x #10402 / Update build scripts to Gradle 9.4.1 from 8.14.4 #11272.
• The quarkus-native module is narrowed to the graalvm21 slot only: Quarkus 3.12.1 requires Mandrel/GraalVM 23.1.0 (JDK 21-based) and rejects the JDK-17-based graalvm17 distribution at the native-image step. The previous Exec-based gate was already broken on that slot for the same reason — this just makes the gate honest via testJvmConstraints { minJavaVersion = 21; maxJavaVersion = 21; nativeImageCapable = true }.