Make it easier to load an implementation of scalafix.interfaces.Scalafix

[bjaglin]

As discussed in #1150 (comment), scalafix-interfaces should provide (Java) helpers for:

• coursier resolution/fetch
• classloading of the correct scalafix-cli

The current helper is pretty low-level:

scalafix/scalafix-interfaces/src/main/java/scalafix/interfaces/Scalafix.java

Lines 71 to 83 in d4f3b8e

	static Scalafix classloadInstance(ClassLoader classLoader) throws ScalafixException {
	try {
	Class<?> cls = classLoader.loadClass("scalafix.internal.interfaces.ScalafixImpl");
	Constructor<?> ctor = cls.getDeclaredConstructor();
	ctor.setAccessible(true);
	return (Scalafix) ctor.newInstance();
	} catch (ClassNotFoundException | NoSuchMethodException |
	IllegalAccessException | InvocationTargetException |
	InstantiationException ex) {
	throw new ScalafixException(
	"Failed to reflectively load Scalafix with classloader " + classLoader.toString(), ex);
	}
	}

This will remove the need for custom code in sbt-scalafix, mill-scalafix, and all other clients.

[olafurpg]

FWIW, in Scalafmt we have a scalafmt-dynamic_2.{11,12,13} library that is written in Scala and provides an implementation of scalafix-interfaces that dynamically loads the correct version of scalafmt-cli. Both Metals and IntelliJ use scalafmt-dynamic to interact with scalafix-interfaces. The benefit of this approach is that scalafmt-interfaces only contains Java interfaces and all the logic is implemented in Scala.

[bjaglin]

I have a local branch almost ready with a pure Java implementation inside scalafix-interfaces (using https://github.com/coursier/interface), which I think is fine. We can discuss once I open the PR!

[bjaglin]

Maybe another benefit of replicating that approach is to try to align classloaders so that scalameta can at some point be shared across scalafmt & scalafix somehow?