Correct AutoConfigurationSorter for source-style nested class name

[TigerZCoder]

Since the AutoConfiguration loaded by org.springframework.core.type.classreading.SimpleMetadataReaderFactory#getMetadataReader(java.lang.String) supports source-style nested class names, developers can register AutoConfiguration in this way. However, if AutoConfiguration is used as an @AutoConfigureBefore/@AutoConfigureAfter reference (class reference in the value attribute), the source-style nested class name registration will fail in the sorting operation.
The failure caused by toSort.contains(after) in org.springframework.boot.autoconfigure.AutoConfigurationSorter#doSortByAfterAnnotation method, which requires the AutoConfiguration class name from @AutoConfigureBefore/@AutoConfigureAfter attribute to be the same as in spring.factories/AutoConfiguration.imports.
This PR fixes this issue by replacing source-style nested class names with class-style nested class names before sorting. For the purpose of minimal modification, this fix is not so elegant. Maybe you can rewrite some code to fit Spring Boot's design ideas.

[wilkinsona]

Thanks for the PR, but I'm not sure that we should do this.

In our experience, auto-configuration classes are almost always top-level classes so the distinction between a . vs a $ separator doesn't arise. For the unusual case where an auto-configuration class is a nested class, I think we would be better to clarify in the documentation that the binary name should be used. This avoids adding complexity to the sorter. It should also perform slightly better elsewhere as well – it will avoid the failed attempt to load com.example.Example.Nested followed by the successful attempt to load com.example.Example$Nested.

Let's see what the rest of the team thinks.

[TigerZCoder]

OK. It would be nice to have explicit rules, or even better to have a lightweight detection warning to help developers fix the sorting failure.

[wilkinsona]

I've opened #44298 to improve the documentation. Unfortunately, I don't think it's possible for detection to be lightweight as there's no way of us knowing for sure if a . should have been a $ without class loading.