Support using projects as step dependency (ktlint rule sets only at this time)

[bric3]

Summary

Ktlint custom rule sets can now be supplied as local Gradle projects:

spotless {
    kotlin {
        ktlint("1.0.1").customRuleSets(
            "com.example:published-rules:1.2",
            project(":ktlint-rules"),
        )
    }
}

This removes the need to rely on configuration-wide dependency substitution when using an unpublished rule set from the same Gradle build. Seen in #1901 (comment)

Motivation

The detached configurations introduced in #2929 are necessary for Gradle 9 buildscript predeclaration. However, detached configurations are not part of the project's configuration container, so rules registered through configurations.configureEach, including dependency substitution, do not apply to them.

Comments in #1901 suggests some builds relied on that undocumented behavior to substitute a published ktlint rule-set coordinate with a local project, as discussed in #1901. Indeed the DSL already supported the idea with an API that allowed to pass maven coordinates. Having the DSL to support local projects seems legitimate.

Implementation

This was trickier than anticipated. As multiple aspects surface in when properly requesting a project.

Here's what changed:

• The API now accept Project instances alongside maven coordinates in customRuleSets.
• This will resolve ktlint, published rule sets, and project rule sets as one dependency graph so Gradle can mediate shared transitive dependencies (it's important as they land on the same classpath).
• Given ktlint version is requested at the Spotless DSL level, I decided to have enforce this version, i.e. if the additional rule set erroneously ships a different ktlint version it will be reported.
• In order to cooperate with the build cache the generated project artifacts are rgistered as task inputs, allowing Gradle to infer producer tasks and track changes without an explicit dependsOn.
• Also, some code was needed in order to cooperate with the configuration-cache and spotlessPredeclare behavior.

---

Please DO NOT FORCE PUSH. Don't worry about messy history, it's easier to do code review if we can tell what happened after the review, and force pushing breaks that.

Please make sure that your PR allows edits from maintainers. Sometimes it's faster for us to just fix something than it is to describe how to fix it.

After creating the PR, please add a commit that adds a bullet-point under the [Unreleased] section of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:

• a summary of the change
• either
  • a link to the issue you are resolving (for small changes)
  • a link to the PR you just created (for big changes likely to have discussion)

If your change only affects a build plugin, and not the lib, then you only need to update the plugin-foo/CHANGES.md for that plugin.

If your change affects lib in an end-user-visible way (fixing a bug, updating a version) then you need to update CHANGES.md for both the lib and all build plugins. Users of a build plugin shouldn't have to refer to lib to see changes that affect them.

This makes it easier for the maintainers to quickly release your changes :)

[bric3]

cc @ntkoopman

[nedtwigg]

Wow! This was very kind of you @bric3, a lot of complexity for an unusual case. This LGTM although we need to fix the windows test failures somehow.

[bric3]

a lot of complexity for an unusual case

Yes, I started minimalist, then other things to consider started to fall apart when tested 😢

[bric3]

oh no my attempted fix didn't work 😢