Convert ChangeDependency to ScanningRecipe to preserve GString/StringTemplate versions

[Jenson3210]

Summary

• Convert ChangeDependency from Recipe to ScanningRecipe to reliably handle version variables in GString and Kotlin StringTemplate dependency declarations
• Simplify ChangeDependency by leveraging the GradleDependency trait's withDeclaredGroupId, withDeclaredArtifactId, and withDeclaredVersion methods
• Fix bugs in the GradleDependency trait where withDeclaredGroupId/withDeclaredArtifactId on K.StringTemplate collapsed the template to a literal (destroying version interpolation), and withDeclaredVersion on G.GString converted to J.Literal (causing the Groovy printer to add unwanted parentheses)

Why ScanningRecipe?

When a dependency uses a version variable (e.g., implementation "group:artifact:${springBootVersion}"), we want to:

1. Preserve the interpolated string structure — only update group/artifact in the literal prefix, keep ${variable} intact
2. Resolve the new version once and update the variable at its definition site (gradle.properties or local def/val)

This requires two passes: a scan phase to discover which variables need updating and resolve the target version, then a visit phase to apply changes. A single-pass Recipe cannot reliably do this because it processes files independently without shared context.

For dependencies without version variables (plain string literals, map notation, multi-component literals), the scanning phase simply collects no variable information, and the visitor applies changes directly — exactly as the old non-scanning Recipe did. The ScanningRecipe conversion has no behavioral impact on these cases.

This approach was recommended in PR #6830 review feedback as the reliable alternative to the ConcurrentHashMap-based approach that depended on file processing order.

What changed

ChangeDependency.java

• Converted from Recipe to ScanningRecipe with an Accumulator that maps version variable names to resolved versions (or MavenDownloadingException)
• Replaced ~400 lines of manual notation-specific code (GString element manipulation, StringTemplate extraction, platform unwrapping) with calls to the GradleDependency trait: withDeclaredGroupId(), withDeclaredArtifactId(), withDeclaredVersion(), getVersionVariable(), getDeclaredVersion(), isPlatform()
• Scanner detects shared version variables (used by both matching and non-matching dependencies) and falls back to collapsing interpolation to a literal in those cases

GradleDependency.java (trait)

• Fixed withDeclaredGroupId and withDeclaredArtifactId for K.StringTemplate: now preserves template structure (updates only the literal prefix) instead of collapsing to a plain J.Literal
• Fixed withDeclaredVersion for G.GString: collapses to a single-element GString instead of J.Literal, which preserves Groovy command expression formatting (implementation "..." stays without parentheses)

Tests

• 3 new ChangeDependencyTest tests for shared version variable detection and collapse
• 6 new GradleDependencyTest tests covering withDeclaredGroupId/withDeclaredArtifactId/withDeclaredVersion on GString and K.StringTemplate
• Updated existing interpolation tests to expect preserved variable references

Test plan

• All 26 ChangeDependencyTest tests pass (23 existing + 3 new shared variable tests)
• All 6 new GradleDependencyTest trait tests pass
• All existing GradleDependencyTest tests pass

Fixes moderneinc/customer-requests#1920