Emit the Java RPC vitest fixture as an ES module (#9895)

`@openrewrite/rewrite/test/java-rpc` was compiled to CommonJS, so its
`import … from "vitest"` became `require("vitest")`, which vitest rejects.
A consumer of the published package could not load the fixture; this
package's own tests run the TypeScript source and never hit it.

The fixture is now `java-rpc.mts`, emitted as `dist/test/java-rpc.mjs`,
and the `./test/java-rpc` export points there. The tests type-check under
`module: nodenext`, which lets a CommonJS file import an ES module.

`JavaRpcTestServer`, `findTestClasspath` and `JavaRpcOptions` are also
exported from `@openrewrite/rewrite/rpc`, for use without vitest.

vitest is declared as an optional peer dependency, since the fixture
imports it from the published package.

Resolve a name of unknown type through the imports in ChangeType's cl…

…ash check (#9889)

ChangeType("a.Response", "b.Response$Builder") wrote `new b.Response.Builder()`
and dropped `import b.Response;` from a file importing `a.Response` where an
earlier recipe had left a name `Response` of unknown type, such as one a
template couldn't attribute.

Since #9861, ChangeType fully qualifies a nested target when another type in
the file takes the name of its outermost class, and it counted every name of
unknown type as one. Such a name now refers to the type the file imports by
that name, so one the file imports as the original or the target's outer class
leaves the name free. One that no import explains still counts, as it can be a
class in the file's own package that isn't on the classpath.

C#: Expose effective language versions on compilation units (#9850)

* Expose effective C# language versions on compilation units

* Preserve C# language versions across frameworks and preprocessor branches

* Account for markers when asserting C# outline node types

JavaTemplate: a call on a bound type variable keeps one method type (#…

…9843)

* JavaTemplate: a call on a bound type variable keeps one method type

J.MethodInvocation.withName gives a call its name's type. So once the
visitor that binds a template's type variables has visited a call's name,
the call's method type is one it bound already, and binding it a second
time expanded a recursive type such as AssertJ's
AbstractOptionalAssert<SELF, VALUE> a level further into a new instance.
The call and its name then had different method types. A type that the
visitor bound is now left as it is.

* State what the set of bound types holds

Retype a method declaration's name along with its method type (#9830)

ChangeMethodAccessLevelVisitor and ExtractInterface.CreateInterface give a
method declaration a new JavaType.Method, but left a typed name on the old
one. Type validation requires a declaration's name, when it has a type, to
have the same instance as the declaration. The parser leaves the name
untyped, so the recipes' own tests passed, but ChangeType types it. In
rewrite-testing-frameworks' JUnit5BestPractices, ChangeType runs before
TestsShouldNotBePublic, and seven tests failed with
"MethodDeclaration#name#type is not the same instance as the MethodType of
MethodDeclaration."

Both now retype a typed name with the new method type, as
ChangeMethodAccessLevelVisitor already does for a call's name.

Raise Java version properties added earlier in the same cycle (#9816)

UpdateMavenProjectPropertyJavaVersion only updated the properties its scan
recorded. When an earlier recipe in the same cycle, such as the same recipe for
a lower Java version, added maven.compiler.release to a pom without Java
version properties, the scan had not seen it, and the property already being
there kept the recipe from adding its own. The lower version then remained
until the next cycle, failing the UpgradeToJava17 and UpgradeToJava25 tests in
rewrite-migrate-java.

JavaScript: add `JsonPathMatcher` to `@openrewrite/rewrite/json` (#9781)

C#: Record project version and identity properties on the MSBuildProj…

…ect marker (#9768)

MSBuildProject.Properties was always empty, so recipes reading the project's
Version or PackageId (such as the NuGet software bill of materials) saw none.
Evaluate each project with MSBuild and record Version, VersionPrefix,
VersionSuffix, PackageVersion, PackageId and AssemblyName when a file in the
repository sets them, with DefinedIn relative to the repository root. SDK
defaults are left out; Version and PackageVersion are also recorded when the
SDK derives them from a version property the repository sets.

C#: give a scanning recipe a fresh accumulator each cycle (#9783)

The C# RPC server kept one accumulator per prepared recipe for the life of the server, so a second cycle's scan added to the first cycle's state, and that cycle's generate and edit acted on both. Java keeps a scanning recipe's accumulator on the cycle's root cursor, which the scheduler creates anew every cycle.

The host sends no cycle number, and the root cursor's RPC id is the same in every cycle, so the server infers the boundary the way the JavaScript and Python RPC servers do. The host scans before it edits in every cycle, so a recipe's first scan after it edited starts a new cycle with a fresh accumulator. A later run that reuses the prepared recipe starts the same way. As in those servers, a cycle whose scan never reaches the server, for example because a hoisted precondition rejects every file, keeps the previous accumulator.

Install ForgeBox packages in the folder CommandBox gives their type (#…

…9765)

- contentbox-modules go under modules/contentbox/modules_user.
- contentbox-themes and contentbox-layouts go under modules/contentbox/themes.
- contentbox-widgets, plugins and interceptors are dropped into
  modules/contentbox/widgets, plugins and interceptors, without a folder of
  their own, whatever their createPackageDirectory says.
- jars go under lib.