Stop using the CompilerClassLoader in sbt-bridge

[adpi2]

Get rid of the hazardous CompilerClassLoader.

As a counterpart it makes the scala compiler bridge incompatible with sbt 1.3.x and Mill older than 0.9.3-21-002361.

EDIT:
My initial goal was to get rid of the CompilerClassLoader but it is probably safer to transition smoothly. So this PR only tries to not use the CompilerClassLoader. When the class loader appears to be badly configured, it prints a warning and falls back to the old technique:

    if(isClassLoaderValid()) {
      return new CachedCompilerImpl(options, output);
    } else {
      log.warn(() -> "The compiler class loader is badly configured.");
      // old implementation
    }

I tested on:

• sbt 1.3.13 with sbt-dotty 1.4.6:

sbt:foo> compile
[info] Compiling 1 Scala source to /home/piquerez/adpi2/foo/target/scala-3.0.0-RC1/classes ...
[warn] The compiler class loader is badly configured.
[success] Total time: 3 s, completed Jan 6, 2021, 11:54:29 AM

• Mill 0.9.3

./millw foo.compile
[27/27] foo.compile 
[info] Compiling 1 Scala source to /home/piquerez/adpi2/foo/out/foo/compile/dest/classes ...
[warn] The compiler class loader is badly configured.
[info] Done compiling.

• Bloop 1.4.6

bloop compile foo
Compiling root (1 Scala source)
[W] The compiler class loader is badly configured.
Compiled root (1961ms)

The warning goes away with sbt 1.4.x (sbt-dotty 1.5.1) and Mill 0.9.4.

[test_sbt]

[adpi2]

@eed3si9n, @lefou, @lihaoyi

Just so you know that this PR will make the compiler bridge of the next Scala 3 version incompatible with sbt 1.3.x and Mill prior to 0.9.3-21-002361.

[adpi2]

Unfortunately it is also incompatible with latest Bloop v1.4.6-15-209c2a5c, so I am going to adapt the class loader in Bloop as well.

[eed3si9n]

acknowledged.

Is there a try-catch or reflection hack you can implement to use the old technique as a fallback?

[adpi2]

@eed3si9n
Yes, that's probably a good thing to do.