Prototype use of ide-starter with gradle-profiler

[asodja]

There are two important parts:

1. Load ide-starter dependencies via a different classloader, so we can use gradle-profiler with Java 8 (unless doing syncs)
2. implement abstraction over ide-starter so we can use it via a nice API

For 1. we have ide-provisiong-api that has just API compiled with Java 8. And then we have also ide-provisioning that is compiled with Java 17.
With Java SPI we then load implementation if required here

gradle-profiler/src/main/java/org/gradle/profiler/studio/StudioGradleClient.java

Lines 77 to 78 in 5ec06de

	URL[] classpath = GradleInstrumentation.getClasspath("ide-provisioning");
	RunIdeStarter ideStarter = ServiceLoader.load(RunIdeStarter.class, new URLClassLoader(classpath, RunIdeStarter.class.getClassLoader())).iterator().next();

At build time we embedded ide-provisioning classpath to the main jar. See the change:
https://github.com/gradle/gradle-profiler/pull/548/files#diff-c0dfa6bc7a8685217f70a860145fbdf416d449eaff052fa28352c5cec1a98c06

[6hundreds]

🤔 This is looks like leaked to API implementation details. Not sure that it's reasonable for API client to manipulate Command terms for running an IDE. Client wants just to invoke fun sync(project, ide), probably add some VM arguments, but that's it.

WDYT?