Run each Spring Boot matrix version as its own Gradle test task #6379

The Spring Boot 2, 3 and 4 matrix workflows test each Boot version by rewriting springboot2/3/4 in gradle/libs.versions.toml with perl, then running the integration suites. A version can only be tested locally by editing the catalog by hand, and each job recompiles the SDK and the suites against that version.

Instead, register one Test task per Boot version that reuses the suite's compiled classes and runs them on a classpath resolved for that version, e.g. :sentry-spring-boot-jakarta:integrationTestBoot3_2_12. integrationTestOtelAgentWithoutAutoInit already reuses a suite's classes this way.

• For each version, add a resolvable configuration that extends the suite's implementation/runtimeOnly and copies runtimeClasspath's attributes. Swap the version with resolutionStrategy.eachDependency { if (requested.group == "org.springframework.boot") useVersion(v) }. This does the same as the perl edit: every catalog entry on springboot2/3/4 is in that group, and so is the BOM, including SpringBootPlugin.BOM_COORDINATES. Libraries pinned to their own version, like spring-kafka3, still win conflicts as they do now.
• The agent suites also need a per-version agentFixture runtime classpath passed to ChildJvmTestArguments, for both init modes.
• Keep the version lists in one place (buildSrc), because the WAR suites in sentry-spring{,-jakarta,-7} need the same list as their Boot module. Put the loop in a helper so six modules don't each repeat it. It fits in the convention plugin from Extract the OpenTelemetry agent test wiring into a convention plugin #6378.
• Add one aggregate task per version for CI to call, and replace the perl step in the matrix workflows with it. That's roughly 80 test tasks (Boot 2: 6 suites × 5 versions, Boot 3: 7 × 4, Boot 4: 8 × 3).

Open problems:

• Boot 2.4–2.6 can't load the GraphQL/Kafka classes. Today bootSupportsGraphqlAndKafka excludes them from the compile. Compiled once against 2.7.18, they'd be in the output, and component scanning on 2.4–2.6 would fail with NoClassDefFoundError. Options: move GraphQL/Kafka into a suite that only runs on 2.7, keep a second compilation with the excludes for the older versions, or drop 2.4–2.6 from the matrix.
• What gets compiled against which version changes. The SDK and the suites would compile once against the catalog default, and only the runtime would vary. For the SDK that's closer to what users run (our published jar on their Boot version) and can catch binary incompatibilities that recompiling hides. But nothing would check any more that the SDK's main code compiles against the oldest supported version. The suite sources must also stick to APIs that exist in the oldest version of each line.
• The Boot 2 suites' JVM 17 Kotlin target pin stays.

CI can keep one job per version (same wall time and per-version PR checks as today, 5–7 min per job) or run one job per Boot line (one compile, less CPU, longer wall time, one check per line).

Start with a spike on Boot 3, which has no GraphQL/Kafka gating: run integrationTest, compiled against the default 3.5.0, on a 3.2.12 classpath.

Do this after the migration stack (#6332 and below) lands, so the in-flight PRs don't need rewriting.