Support configuration cache

[C-Otto]

When using version 2.0.1 of the plugin with Gradle 7 (RC2) with --configuration-cache, the configuration cache can be created, but the project does not build when it is used. Key error message:
> Extension with name 'errorprone' does not exist. Currently registered extension names: [ext]

Reproducer: https://github.com/C-Otto/playground/tree/errorprone-configuration-cache

Creating configuration cache (successful):

$ ./gradlew clean build --no-build-cache --configuration-cache
Configuration cache is an incubating feature.
Calculating task graph as no configuration cache is available for tasks: clean build

BUILD SUCCESSFUL in 4s
12 actionable tasks: 12 executed
Configuration cache entry stored.

Second build, reusing configuration cache (fails):

$ ./gradlew clean build --no-build-cache --configuration-cache
Configuration cache is an incubating feature.
Reusing configuration cache.
> Task :subproject-one:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':subproject-one:compileJava'.
> Extension with name 'errorprone' does not exist. Currently registered extension names: [ext]

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 679ms
4 actionable tasks: 4 executed
Configuration cache entry reused.

[tbroyer]

I must say I'm a bit surprised, because there's a test that should cover that:

gradle-errorprone-plugin/src/test/kotlin/net/ltgt/gradle/errorprone/ErrorPronePluginIntegrationTest.kt

Line 170 in bac9e13

fun `is configuration-cache friendly`() {

AFAICT, the main difference is that the test doesn't explicitly configure options.errorprone, and that probably explains the difference in behavior here.

[tbroyer]

OK, finally understood what goes wrong: for some reason, the extension is (unexpectedly) not registered when the task is executed, so the doFirst action cannot get it out from the task. The extension object is "in scope" though so simply using it rather than retrieving it from the ExtensionContainer is enough to workaround the problem.

This is unrelated to whether the build script explicitly configures the extension or not, and the reason the test didn't caught it is because it didn't actually re-run the task (it's up to date).

[tbroyer]

I published v2.0.2 with that change.