Streamline our infrastructure with Gradle Convention plugins

[Jolanrensen]

Related to #1614

The DataFrame project infrastructure has become large, complex, and fractured, making it difficult to maintain, and we often forget to bump versions in places because they are not synced.

I've been experimenting with gradle convention plugins and composite builds: https://github.com/Jolanrensen/GradleConventionsExperiment

I believe this sample project can be used as a good base for the DataFrame project itself:

• (type safe) convention plugins allow us to remove duplicate build code and avoid using allProjects {}
  (It's also the recommended way to structure builds according to Gradle and Kotlin)
• It fixes the issue where we have to manually sync versions to subprojects like /plugins/keywords-generator. We can simply use a build-settings convention plugin that finds and sets up the correct version catalog :)
• See https://github.com/Jolanrensen/GradleConventionsExperiment for more information and links

We could introduce it gradually:

• Enable build-settings-logic and build-logic with just version catalogs, start using it for nested projects (fixed by: Gradle conventions init and shared version catalogs #1662)
• Move allProjects {} logic into dedicated conventions (like dfbuild.kotlinJava8 and dfbuild.kotlinJava11, for instance) Convention plugins part 2 (and disable KSP/Gradle plugin) #1670
• Fix our examples situation: Make :examples be separate projects and use the compiler plugin #1614 and Update android example #1610, WIP: Examples separate projects #1677
• Create "common dataframe IO plugin" convention which provides and sets up plugins we use everywhere, like KtLint, binary compatibility validator, publisher, build config
• Move Korro logic into dedicated convention (we now have duplicate logic in :core and :samples)
• Move KoDEx logic into dedicated convention (duplicated in :core and :dataframe-csv) KoDEx convention plugin #1765
• Make the setup for running the compiler plugin inside local modules a convention plugin (currently worked out in :samples, but we might need it in other places later as well). Alternatively, we could turn :samples into a separate project, like the examples.
• Move :plugins:expressions-converter, :plugins:keywords-generator, and :plugins:public-api-modifier (if we actually use that one) into build-logic. They are only used from local build files, so essentially, they're already convention plugins.
• Create a convention plugin for running our tests against all LTS java versions Support Java Record in toDataFrame conversion #1682 (comment)
• Move :core:dependencyUpdates task to convention plugin. It depends on dataframe via our old KSP plugin which will not be published anymore for beta5+ See dependencyUpdates convention plugin #1821

[koperagen]

Create a convention plugin for running our tests against all LTS java versions #1682 (comment)

// Multi-JDK testing: run main tests (compiled with JDK8 compatibility) on different JDK versions
listOf(8, 17, 21).forEach { majorVersion ->
    val jdkTest = tasks.register<Test>("testJdk$majorVersion") {
        javaLauncher = javaToolchains.launcherFor {
            languageVersion = JavaLanguageVersion.of(majorVersion)
        }

        description = "Runs the main test suite on JDK $majorVersion"
        group = LifecycleBasePlugin.VERIFICATION_GROUP

        // Copy inputs from normal Test task (JDK8-compiled tests)
        val testTask = tasks.test.get()
        classpath = testTask.classpath
        testClassesDirs = testTask.testClassesDirs
        maxHeapSize = "2048m"
    }
    tasks.check {
        dependsOn(jdkTest)
    }
}