Avoid eager creation of tasks for Spotless plugin

[bigdaz]

Previously applying the Spotless plugin resulted in a many tasks to be created
per subproject, even for an invocation like gradle help.
Using "Task configuration avoidance" APIs means that these tasks will
not be constructed if they will not be required during task execution.

[nedtwigg]

This LGTM, merge at will! If you have code-in-progress for the Provider<> stuff, I'm eager to see it. Or if you'd like me to send up a PR for us to look at with the // TODO override configure(String name, Class<T> clazz, Action<T> configure) so that it is lazy idea, I'm happy to do that.

[bigdaz]

Thanks Ned. In the end I didn't bother trying to get rid of the afterEvaluate and the migration to Task config avoidance APIs was pretty straightforward.

I'm not sure what you intend for making configure lazy, so I might leave that to you.

FYI I'm having an issue running spotlessApply on the master branch in my fork. I suspect it's got to do with the fact that it was renamed to main in the primary repo, but I'm not sure. Here's a build scan with the failure: https://scans.gradle.com/s/svlbtvyqgiwj2/failure. Once the PR is merged I'll see what I need to do to get it working, but I presume a NPE isn't the intended behaviour :).

[bigdaz]

I can confirm that by deleting and re-creating my fork on GitHub, the above issue is resolved.

[nedtwigg]

Yup, def some transients in the master -> main transition :). I'll take a quick crack at the lazy idea I had, and I'll throw it up to get your feedback on its pros/cons vs Provider<> approaches.

[nedtwigg]

Part of #601