[infra] add parameterized runTarget to allow running against custom IDE targets

[pq]

Adds support for running the plugin against custom target IDEs using the new intellijPlatformTesting Gradle extension, introducing a new parameterized runTarget.

Why not update runIde directly?

In the new IntelliJ Platform Gradle Plugin (v2.x), the default runIde task is strictly bound to the main project dependency used for compilation (which is Android Studio in our project). To run against a different IDE without changing the compilation target (which would break compilation due to our project's hard dependencies on Android Studio APIs), the plugin requires using the intellijPlatformTesting extension to register a custom task. We can't easily re-target the default runIde task without also changing what we compile against. (And if we don't change what we compile against we're in the reflection business so we can compile in the absence of AS deps OR code splitting which is a headache; see relevant conversation in #8865.)

Details

• Registers a custom runIde task named runTarget in build.gradle.kts.
• Added support for -Pide (values: AndroidStudio, IntelliJ, Ultimate) and -PideV (version string or build number) properties.
• Adds a self-documenting help output to runTarget that lists available options and examples when run without parameters, and then exits without launching the IDE.
• Updates the existing printProductsReleases task to include instructions on how to map its output to the new -Pide and -PideV parameters.

---

Sample Outputs

1. Running runTarget without parameters

Running the task without parameters prints a help report and stops execution.

./gradlew runTarget

============================================================
runTarget - Available Options
============================================================
Valid values for -Pide:
 - AndroidStudio (default)
 - IntelliJ (IntelliJ IDEA Community)
 - Ultimate (IntelliJ IDEA Ultimate)

Valid values for -PideV:
 - Any valid version string for the selected IDE.
 - Examples for IntelliJ/Ultimate: 2024.1, 2024.2, 2024.3, 2025.1
 - Run './gradlew printProductsReleases' to see the full list.

Examples:
 ./gradlew runTarget -Pide=IntelliJ -PideV=2025.1
 ./gradlew runTarget -Pide=Ultimate -PideV=2025.1
============================================================
Stopping execution. Please run with parameters to launch a specific IDE.

2. Running printProductsReleases

The task now prints mapping instructions after listing the available releases.

./gradlew printProductsReleases

IU-261.23567.71
IU-253.31033.53
IC-252.27397.28

Mapping printProductsReleases output to ideV:
 - The prefix (e.g., IU-, IC-) maps to -Pide (Ultimate, IntelliJ).
 - The number part (e.g., 261.23567.71) maps to -PideV.
 - Example: IU-261.23567.71 -> -Pide=Ultimate -PideV=261.23567.71

Fixes: #8909

---

Review the contribution guidelines below:

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.
• I've included the required information in the description above.
• My up-to-date information is in the AUTHORS file.
• I've updated CHANGELOG.md if appropriate.

Contribution guidelines:

• See
  our contributor guide and
  the Flutter organization contributor guide
  for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Dart contributions to our repos should follow the Dart style guide and use
  dart format.
• Java and Kotlin contributions should strive to follow Java and Kotlin best
  practices (discussion).

[gemini-code-assist]

Code Review

This pull request introduces a runTarget Gradle task to facilitate testing the plugin against various IDE targets and versions via command-line properties. It also updates CONTRIBUTING.md with usage instructions and enhances the printProductsReleases task with mapping guidance. Review feedback suggests improving consistency in the help message examples and refactoring the runTarget task definition into a single configuration block to enhance maintainability and prevent variable shadowing.

[pq]

Proof of the puddin...

[pq]

@cj-radcliff, @helin24: after a bunch of noodling around I found https://plugins.jetbrains.com/docs/intellij/tools-intellij-platform-gradle-plugin-testing-extension.html which explains some of the headaches we were having w/ runIde and offers up a pretty simple and uninvasive solution.

It's pretty straightforward to use but since I know I'll forget, I inlined some help docs (see examples above). If anything looks unclear or unobvious, let me know!

[cj-radcliff]

@cj-radcliff, @helin24: after a bunch of noodling around I found https://plugins.jetbrains.com/docs/intellij/tools-intellij-platform-gradle-plugin-testing-extension.html which explains some of the headaches we were having w/ runIde and offers up a pretty simple and uninvasive solution.

It's pretty straightforward to use but since I know I'll forget, I inlined some help docs (see examples above). If anything looks unclear or unobvious, let me know!

This is super helpful.

[helin24]

Very cool! So this installs the result of buildPlugin into the specified IDE?

[pq]

Very cool! So this installs the result of buildPlugin into the specified IDE?

Yep. One of the biggest pluses (that I forgot to highlight above) is that what we're testing is basically the same as what we're releasing. (This would be different if the compilation and execution targets were coupled.)