Investigate use of JUnit ClasspathScanner for class discovery

[holly-cummins]

For a while, we've wanted the ability to intercept JUnit class discovery, without writing a whole engine. So far, it hasn't been possible, but that is changing soon.

The approach used in #34681 is to use a Launcher interceptor, along with a facade classloader. The new (in >=5.12) capability to use a ClasspathScanner might be a simplication. See junit-team/junit5#3628 for some details. We'd want to implement List<Class<?>> scanForClassesInClasspathRoot(URI root, ClassFilter classFilter).

Although this would be a pleasing simplification, it doesn't help with the majority of the complexity involved in #34681; we still need to move the application creation code from where it is today, we still need to pre-create all of the applications needed by the tests, and we'd probably end up with something fairly similar in its implementation to the facade classloader, even if it doesn't actually implement the classloader interface. And we still need to fix all the things broken by moving the runtime classloader creation forward. So I think we should keep this enhancement in mind, but not block for it.

TLDR: Implemening ClasspathScanner rather than Classloader would be semantically cleaner, but functionally fairly similar to what we're planning to do #34681.

/cc @dmlloyd @geoand

[geoand]

Thanks for the update!