Rework how the compiler plugin is loaded The previous implementation had a performance regression due to the inclusion of `tools.jar` on the worker classpath. Some classes of the Java compiler were loaded multiple times. To avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load it in isolation in the same classloader as the loader which has `tools.jar`.
Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication" with Gradle, for example the intelligence of relativizing paths or writing the generated mapping file, is done passing lambdas to the compiler.
Last but not least, this also means that the construction of the incremental compile task has to be done via reflection (otherwise we would load the task in the wrong classloader).