Support lazy file collections for GenerateJavaTask.schemaPaths

[jiholee17]

Closes #952

Summary

Update GenerateJavaTask.schemaPaths to support lazy Gradle file inputs while preserving compatibility with existing consumers.

Why

Schema paths may come from a resolvable dependency configuration. Requiring callers to convert that configuration to files eagerly causes dependency resolution during Gradle’s configuration phase.

The previous path conversion also called toString() on each list element. If a collection such as Set<File> was accidentally added as one element, it became a path containing literal brackets—for example, [/path/to/schema.graphqls].

Changing schemaPaths directly to a ConfigurableFileCollection was considered, but that changed the JVM return type of getSchemaPaths(). Downstream plugins compiled against the existing mutable List API then failed with NoSuchMethodError.

What changed

• Keep schemaPaths as MutableList<Any> to preserve source and binary compatibility.
• Annotate schemaPaths directly with @InputFiles.
• Add setters accepting:
  • FileCollection, including resolvable Configuration instances
  • Provider<out Iterable<Any>>
• Store providers and file collections without resolving them during configuration.
• Resolve task inputs through Gradle’s FileCollection notation handling.
• Flatten nested providers, file collections, and iterable file inputs instead of converting them to strings.
• Remove the separate derived schemaFiles input property, simplifying the implementation while preserving content-based up-to-date checking.

Relative paths now use Gradle’s normal file-collection semantics and resolve against the project that owns the generateJava task.

Compatibility

getSchemaPaths() continues to return java.util.List, so existing integrations using calls such as the following remain compatible:

task.getSchemaPaths().addAll(files);

This avoids breaking convention plugins already compiled against the existing API.

Tests

Added functional coverage for:

• Lazy Provider resolution
• Lazy resolvable Configuration/FileCollection inputs
• Nested Set<File> flattening
• Content-based up-to-date checking
• Mutable-list/JVM getter compatibility
• Relative string and File paths in multi-project builds