Reduce nested class lookups in ClassUtils

[bclozel]

While working on #31213, I have noticed that Framework performs more class lookups than we thought.

For example, we need to register reflection on jakarta.inject.Inject types; even if the type is not present on the classpath at build time, the application might try to load it at runtime anyway. If the class is not present at runtime, ClassUtils#forName will try to load both jakarta.inject.Inject and jakarta.inject$Inject.

While I understand the rationale for nested classes, I think we need to consider the following proposals:

1. This is the expected behavior, so we'll need to amend our reflection hints engine to automatically register nested class variants no matter what. This could be the best solution for our 6.0.x branch.
2. As part of 6.1, we could consider toning things down and only attempting to resolve nested classes if the previous segment starts with a capital letter (which is more typical for a class name), like org.example.Spring.Issue -> org.example.Spring$Issue. This could also benefit most JVM applications by reducing the amount of unnecessary lookups.
3. Eliminate nested classes entirely; I'm not sure this is the right approach as we're likely to break existing apps for no added benefit.

Any opinion @jhoeller @snicoll ?

[jhoeller]

Only trying the nested class syntax in case of an upper-case segment before looks like a good way out, covering the common cases that we are trying to optimize for.

[bclozel]

Thanks Juergen, I'll use this issue to apply that change in 6.1.