Share artifact cache across JavaSourceSetUpdater visitors

[steve-aom-elliott]

What

JavaSourceSetUpdater (introduced in #7202, refined by #7358 / #7373 / #7376) downloads each newly-added or changed dependency's JAR so it can refresh the in-memory JavaSourceSet marker with the new types. Two pieces of state were not shared across visitors:

1. The artifact cache. The constructor allocated a fresh Files.createTempDirectory("rewrite-artifact-cache") and wrapped it in a LocalMavenArtifactCache per visitor instance, so the same JARs were re-downloaded across recipes in a run.
2. The result of scanning the JAR. JavaSourceSet.typesFromPath(jarPath, null) re-opens the JAR and re-walks its entries on every call, even though the result is a pure function of the GAV's bytes.

Every dependency-mutating recipe (AddDependency, UpgradeDependencyVersion, ChangeDependency, ChangeDependencyGroupIdAndArtifactId in both rewrite-maven and rewrite-gradle) constructs its own updater, so both costs were paid per recipe per source set.

This PR shares both, scoped to the ExecutionContext.

Why

Migration recipe chains (e.g. Spring Boot 3 → 4) trigger dozens of dependency-mutating recipes per repository. Without sharing, the same JARs are re-downloaded and re-scanned across the run — multiplying outbound traffic to Maven Central / artifactory and burning CPU on redundant JAR walks.

How

1. Shared MavenArtifactCache on MavenExecutionContextView

Mirrors the existing MavenPomCache pattern:

• New MAVEN_ARTIFACT_CACHE message key.
• New setArtifactCache(MavenArtifactCache) setter for embedders that want to override (e.g. point at a persistent volume).
• New getArtifactCache() that lazily defaults to a LocalMavenArtifactCache at ~/.rewrite/cache/artifacts (the same directory JavaRewriteRpc already uses), falling back to a single JVM-lifetime temp directory if the user home isn't writable.
• JavaSourceSetUpdater constructor now resolves its downloader's cache from mctx.getArtifactCache() instead of allocating a per-visitor temp dir.

2. Memoized typesFromPath results on the ExecutionContext

• JavaSourceSetUpdater reads/writes a Map<String, List<JavaType.FullyQualified>> stored on the ctx under "org.openrewrite.maven.jarTypeCache", keyed by groupId:artifactId:version.
• Only positive results are cached. addDependency tries each repository in order until one succeeds, so caching empty results would short-circuit later repos.

Tests

New MavenExecutionContextViewTest:

• artifactCacheIsMemoizedAcrossCalls — repeated getArtifactCache() calls return the same instance.
• setArtifactCacheOverridesDefault — setArtifactCache(...) overrides the lazy default.
• artifactCacheIsSharedBetweenViewsOverSameDelegate — load-bearing: each JavaSourceSetUpdater calls MavenExecutionContextView.view(ctx) freshly, so the cache must live on the underlying delegate's message map, not on the view.

New JavaSourceSetUpdaterTest:

• typeCacheIsSharedAcrossUpdaters — two updaters built from the same ctx see the same type-cache map.

Existing tests still pass: ChangeDependencyGroupIdAndArtifactIdTest (full class, including updatesJavaSourceSetMarkerOnJavaFiles), AddDependencyTest and UpgradeDependencyVersionTest in both rewrite-maven and rewrite-gradle, and ChangeDependencyTest in rewrite-gradle.