[BUG] Setting a relative templateDir using GenerateTask in 6.2.1 results in a configuration exception at build time.

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

Setting a relative templateDir using GenerateTask in 6.2.1 results in a configuration exception at build time.

A problem was found with the configuration of tas (type 'GenerateTask').
- In plugin 'org.openapi.generator' type 'org.openapitools.generator.gradle.plugin.tasks.GenerateTask' property 'templateDir' specifies directory which doesn't exist.

This exception occurs when the directory is on the class path and loaded from a library JAR.

In 6.2.1 this field was updated to include a PathSensitive annotation. This annotation looks to be causing the exception.

    @PathSensitive(PathSensitivity.RELATIVE)
    val templateDir = project.objects.property<String?>()

openapi-generator version

6.2.1, the exception does not occur in 6.2.0

Steps to reproduce

Use openapi-generator 6.2.1 and configure a template dir.

tasks {
    register<GenerateTask>("generateApiClient") {
        templateDir.set("templates/kotlin")
    }

Include a JAR on your class path that includes a resources folder with a templates/kotlin folder that includes a set of template overrides.

Suggest a fix

A simple fix could be to revert this change and remove the @PathSensitive(PathSensitivity.RELATIVE) annotation from templateDir.

Start by locating GenerateTask and its templateDir property, then inspect the PathSensitive annotation described in the issue. Reproduce the Gradle configuration with a classpath JAR containing resources/templates/kotlin and compare it with version 6.2.0. Done means a relative templateDir loaded from that JAR no longer causes the configuration exception.