feat: add kotlin compiler args to gradle plugin

[taefi]

Description

Vaadin-Hilla apps can be written in Kotlin with either Gradle or Maven. This PR is only addressing the Gradle side (since it is
the default in SpringBoot projects downloaded from spring initializr. The same can be done for the Maven but in a different PR, since the approach is totally different.

The approach of this PR was to use reflection to dynamically add the compiler arges to the compileKotlin task, so that users don't have to do it manually in their projects. The reflection approach has the following benefits:

• It only needs the kotlin-reflect dependency to be available in the user projects, and since that dependency is needed in almost all the Kotlin SpringBoot projects because of the limitations of Kotlin closed classes e.g. in spring-data-jpa, no extra dependency is imposed to user projects.

This could've been done in another way, without reflection, as follows:
HillaPlugin.kt

project.plugins.withId("org.jetbrains.kotlin.jvm") {
      project.tasks.withType(KotlinCompile::class.java) { kotlinCompile ->
          // Configure Kotlin compiler options
          kotlinCompile.compilerOptions { kotlin ->
              kotlin.freeCompilerArgs.addAll(
                  listOf(
                      "-Xjsr305=strict",
                      "-Xemit-jvm-type-annotations"
                  )
             )
        }
    }
}

But, this needs KotlinCompile class to be available in the buildScript classpath (the classpath for the plugins and the processing of the build file, not the user application code), user projects need to add a buildScript block in either their build.gradle or settings.gradle to add the following dependency for our plugin:

settings.gradle

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.9.25")
    }
}

This approach has a benefit that is more robust when upgrading gradle version, and possible errors in case of deprecation/removal of the used API would be easily noticed, while the reflection approach would fail at runtime (which can be covered by tests instead).

Part of #2343

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.60%. Comparing base (efc7da0) to head (6f0dc1c).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3156   +/-   ##
=======================================
  Coverage   92.60%   92.60%           
=======================================
  Files          85       85           
  Lines        3164     3164           
  Branches      775      775           
=======================================
  Hits         2930     2930           
  Misses        183      183           
  Partials       51       51           

Flag	Coverage Δ
unittests	92.60% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cromoteca]

It's just a comment, but I'm requesting changes to make it visible.

[cromoteca]

I wonder if one of those invokes can return null

[taefi]

Technically, when the Kotlin jvm plugin is applied, the compileKotlin task and its options cannot be null. But, because of executing methods dynamically using reflection, added null check guards for cases such as API removal in future, or other possible edge cases we are not aware of atm.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud