[#250 clone] Run ktlint in process isolation + allow overriding ktlint version

[mateuszkwiecinski]

Clone of #250 with my suggested improvements/changes

1. new configurations will be automatically configured, even for custom tasks
2. It's possible to override ktlint version
3. @hrach's custom rules were migrated to new ktlint 0.47.1 apis
4. I slightly changed the way errors are reported back
5. Plugin itself won't expose ktlint dependency anymore to its consumer (it's defined as compileOnly now)
6. default runtime ktlint version is kept in sync with the one compilation uses
7. [new] It doesn't only uses ktlint APIs, but also resolves rules from the ktlint version provided via plugin extension

Fixes #280
Fixes #34

[mateuszkwiecinski]

Potential blocker: gradle/gradle#21964

[Karn]

Hey @mateuszkwiecinski! Looking forward to this PR! I'm wondering if you have considered just manually loading the custom rules using something like:

fun ktlintRulesetsFromClasspath(classpath: ConfigurableFileCollection): List<RuleSetProviderV2> {
    // Load the files from the classpath into a new ClassLoader
    @Suppress("DEPRECATION")
    val fileUris = classpath.map { it.toURL() }.toTypedArray()
    val classLoader = URLClassLoader(fileUris, Thread.currentThread().contextClassLoader)
    return ServiceLoader.load(RuleSetProviderV2::class.java, classLoader).toList()
}

Where classpath here is the ktlintClasspath. That way we can bypass the processIsolation issues, at least temporarily.

[mateuszkwiecinski]

@Karn Thanks for sharing the idea💡
I haven't considered any workarounds yet, mainly because the process isolation works just fine. I did some manual testing, and it all worked like a charm. The blocker I stumbled upon turned out not being related to the process isolation, but rather the quirky behavior of Gradle TestKit testing framework 🤷
I disabled problematic tests on Windows, and the PR should soon reach reviewable state :)

[mateuszkwiecinski]

I wasn't sure how to reflect the ktlint version can be overriden. the text block above mentions these are the defaults, and the default value is the current ktlint version (the one kotlinter is compiled with, to be more precise)

[mateuszkwiecinski]

As an alternative, I can propose having some sort of hardcoded value that will be mapped into "our" ktlint version, i.e.

Suggested change

	ktlintVersion = "x.y.z"
	ktlintVersion = "default" // or `latest` or `current`? but that might be too confusing

[jeremymailen]

I usually show the default value if you don't configure anything.
Which I suppose also causes a little confusion because people explicitly configure it not realizing that's what they get by default.

[mateuszkwiecinski]

This is not ideal tests, and will likely fail when upgrading ktlint version, but I was out of ideas and decided to defer writing better assertion to somewhen later 😬
What I want to test here is to somehow replace the old test relying on test classpath, with something that covers the dynamic loading part.

[hrach]

Friendly reminder - it would be great to have the functionality for custom rules. Thank you.