While multiproject reloading was possible before Grails 6, it was rather difficult to configure, the following had to be done:

1. the property grails.run.active was set
2. the plugin project had the property exploded set to true prior to the application of the grails-plugin Gradle plugin
3. plugins were added to the Grails Application project via the plugins block inside of the grails extension in build.gradle instead of the dependencies block
4. the property exploded was set on the grails extension in build.gradle of the Grails Application project

This PR cleans up this process by adding a new gradle plugin org.apache.grails.gradle.grails-exploded, now the following has to be true for reloading to work:

1. In the plugin project, apply the gradle plugin org.apache.grails.gradle.grails-exploded
2. In the application project, define plugins inside of the plugins block of the grails extension in build.gradle:

As part of this PR, I have also:

1. cleaned up old variables on GrailsGradlePlugin that are no longer used since we adopted the grails-bom
2. moved the groovy compilation configuration back into compileGroovy.

For the groovy compile configuration changes, the core issue is we need to be sure a non-cached version of the configuration file is generated whenever groovy would recompile / not cache. The issue is to do this we need to depend on the runtimeClasspath - if the build changes we need to rerun, if the project switches from application to a plugin we need to rerun, if the project name changes rerun, if the version changes rerun, etc. This means that any task that interacts with the runtime classpath, now needs to declare a dependency on our customization task. This really makes the build fragile and is the reason I've moved the configuration back into doFirst { }. When gradle changes the configuration to be provider based, I think we can revisit this.