Fix AddSettingsPluginRepository duplicate pluginManagement and repository handling

[timtebeek]

Summary

• Fix AddSettingsPluginRepository to correctly detect existing pluginManagement blocks wrapped in J.Return (Kotlin settings files)
• Add comprehensive test coverage for URL-less repository types (gradlePluginPortal, mavenLocal)

Problem

The AddSettingsPluginRepository recipe has two bugs:

1. It may add a repository even if it already exists (e.g. gradlePluginPortal() when already present)
2. It may add an entire duplicate pluginManagement block

The root cause is that addPluginManagementRepos() only checked for J.MethodInvocation as the first statement, but in Kotlin settings files the parser wraps the last expression in J.Return, so the existing pluginManagement block was not recognized and a duplicate was inserted.

Solution

• Added J.Return unwrapping when detecting existing pluginManagement blocks in addPluginManagementRepos()
• When writing back modified pluginManagement, re-wraps in J.Return if the original was wrapped
• Added 20 new test cases covering: skip-when-exists for gradlePluginPortal/mavenLocal (Groovy+KTS), no-duplicate-pluginManagement-block scenarios, idempotency (3 cycles), complex settings files, and adding repos to existing blocks

Test plan

• All 20 new tests pass

• All existing tests pass

• Idempotency verified with 3-cycle tests

• Fixes moderneinc/customer-requests#1986

[MBoegers]

I retuced the number of tests as there where a lot of duplicates.