Improved handling of inner class named $ in JavaTemplate

[MBoegers]

What's changed?

• TypeUtils handle $ better if determing the FQN
• use TypeUtils in rewrite-java*

What's your motivation?

I want the fix the handling of $ as class name.
And fixing

• Problem with inner Class named '$' in JavaTemplate #3623

Have you considered any alternatives or workarounds?

Any additional context

If finished this should enable
-openrewrite/rewrite-migrate-java#285

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

Great to see, thanks @MBoegers ; saving others a click by copying the remaining failure here:

JavaTemplateSubstitutionsTest > anyForInnerClass() FAILED
    org.opentest4j.AssertionFailedError: [Unexpected result in "A.java":

diff --git a/A.java b/A.java
index df29fc4..f075a84 100644
--- a/A.java
+++ b/A.java
@@ -1,6 +1,6 @@ 
 class A {
     void foo() {
-        $ test = new $();
+        $ test = new A.$();
     }
     static class $ {
         static $ of() {

    ] 
    expected: 
      "class A {
          void foo() {
              $ test = new $();
          }
          static class $ {
              static $ of() {
                  return new $();
              }
          }
      }"
     but was: 
      "class A {
          void foo() {
              $ test = new A.$();
          }
          static class $ {
              static $ of() {
                  return new $();
              }
          }
      }"

[knutwannheden]

A JavaType.FullyQualified instance currently typically uses the binary name, which in the compiler's AST is represented by Symbol#flatName().

I think that instead of changing and using TypeUtils.toFullyQualifiedName() to get the fully qualified name of a instances implementing JavaType.FullyQualified we would be better off either changing the internal representation or deriving the name from the current representation.

Changing the current internal representation is trickier (with regards to backward compatibility), but adding a utility that can return the "source name" for a JavaType.FullyQualified instance should be possible by combining what is returned by getOwningClass() and by getFullyQualifiedName().

I am saying this because a class could also be called Foo$Bar if you wanted to and that is another $ we shouldn't be replacing.