Remove past-due @ToBeRemoved code and enable RemoveToBeRemoved in rewrite.yml

[timtebeek]

Ran org.openrewrite.java.recipes.RemoveToBeRemoved and enabled it in rewrite.yml; the first commit is the recipe's raw output, the second fixes what it leaves behind (it deletes declarations but explicitly not their references).

Most past-due annotations sat on private shims for older parent runtimes (getStyle, addStyleMarker, evaluate, shouldKnowInflowStyle), so their callers now go to org.openrewrite.style.StyleHelper directly — with an explicit (Supplier<X>) cast, because StyleHelper.getStyle(Class, List, Supplier) and getStyle(Class, List, T extends SourceFile) are ambiguous to javac for a lambda or method reference. Removing J.VariableDeclarations' deprecated dimensionsBeforeName constructor means the Java 8/11 parser visitors, GroovyParserVisitor and one test drop that always-empty argument, and removing JavaParser.Builder.classpath(byte[]...) takes JavaParserTest#parseFromByteArray, its .class fixtures and the now-unused classgraph test dependency with it.

Two things left alone and worth a reviewer's call: protected Collection<byte[]> classBytesClasspath now has no in-repo writer, so the ByteArrayCapableJavacFileManager path is reachable only by external subclasses — ripping the plumbing out would change protected API across five parser modules; and the six // TO-BE-REMOVED(date) comments (five past due) are out of the recipe's reach, since its precondition is UsesType(ToBeRemoved) and none of those files import the annotation.

Verified with compileJava compileTestJava across every module, the rewrite-java/-test/-groovy/-kotlin/-yaml/-hcl test tasks, and compatibilityTest (TCK) on all five parser modules; the only remaining @ToBeRemoved is J.MethodDeclaration's, dated 2026-09-17, so the newly enabled recipe is a no-op until then.

[timtebeek]

Serialized-LST compatibility review

@ToBeRemoved's own javadoc says removals "should, where applicable, also account for LST models that were serialized in the past to not cause deserialization errors", so I went back over this diff for that specifically. Only two of the removals touch LST types at all; the rest are format-visitor shims and a parser-builder method.

Hcl.TemplateInterpolation's @JsonCreator constructor

• Fix HCL parser idempotency issue with spaces before closing brace #6076 landed on 2025-09-30, so LSTs written against the older expression model are outside the support window and the constructor can just go.

J.VariableDeclarations' dimensionsBeforeName members

I believe these are safe to remove, but flagging the reasoning so someone closer to the serializer can check me.

• Fixes for Java RPC #5704 already deleted the backing field back in July 2025 and left only no-op shims:

getDimensionsBeforeName() returned emptyList(), withDimensionsBeforeName(...) returned this, and the 9-arg constructor ignored the argument. Nothing readable is lost, an old payload's dimensionsBeforeName is both ignorable and always empty, and the explicit @JsonCreator sits on the 8-arg @RequiredArgsConstructor, so creator selection doesn't shift. There are no references to the name anywhere else in the repo, including the RPC codecs.

Not LST-related, but still a break

J.VariableDeclarations' 9-arg constructor, getDimensionsBeforeName/withDimensionsBeforeName, and JavaParser.Builder.classpath(byte[]...) are all public API, so external callers compiled against them get a NoSuchMethodError. That's the intended effect of a past-due @ToBeRemoved rather than a surprise, but worth naming explicitly since it's a different kind of risk from the deserialization one above.