Update Gradle cache with the configurable plugin support

[matikepa]

Adds configurable Maven upstream support and Gradle Plugin Portal fallback for Gradle plugin marker artifacts on the Maven endpoint.
Introduces new upstream config/env options, wires them through server startup, and extends Maven artifact handling to include .module files.
Tests were added/updated to validate fallback and caching behavior for plugin markers, including real-world plugin coordinates.

[matikepa]

hi @andrew

this is a followup to the #87 where i have overlooked potentially missing fallback case.

Namely the Gradle plugin marker resolution may still be hitting Maven Central instead of the Gradle Plugin Portal, which can lead to 404 errors.

[andrew]

Thanks for the follow-up, the marker detection logic is correct and the config wiring matches the existing upstream pattern. A few things before merging:

Checksums and metadata don't fall back. .sha1/.sha256/.md5 and maven-metadata.xml are routed through isMetadataFile to h.upstreamURL only, with no Plugin Portal fallback. I checked com.diffplug.spotless.gradle.plugin-8.4.0.pom.sha1: 404 on Central, 200 on the Plugin Portal. So the POM resolves but its checksum doesn't, which breaks builds with verification-metadata.xml enabled. The metadata path needs the same fallback treatment for marker coordinates.

Duplicate tests. TestMavenHandler_GradlePluginMarkerFallbackAndCache and the _BenManes variant are identical apart from the path string. Please collapse them into one table-driven test.

Minor: the h.pluginPortalUpstreamURL == "" check in shouldFallbackToPluginPortal is unreachable since the constructor always sets a default. Fine to drop it.

One thing to flag for a follow-up rather than this PR: the fallback only covers *.gradle.plugin marker artifacts. Once Gradle reads the marker it fetches the implementation jar (e.g. com.diffplug.spotless:spotless-plugin-gradle), which won't match the suffix and goes to Central only. Spotless publishes to both so it works, but Portal-only plugins will still fail at that step. The README now suggests pluginManagement { maven(...) } is fully handled, so worth either a caveat in the docs or a broader fallback later.