Move run-targets into RunModule

[lefou]

This PR moves the definition of the run targets from JavaModule into RunModule. Also some other targets where moved, e.g. mainClass, finalMainClassOpt and finalMainClass.

The advantage of having them in RunModule is, that one can easily define and configure additional runners as sub-modules.

Example: Define a daemon sub-module which acts as runner for the cli.DaemonTool class.

import mill._, scalalib._

object foo extends RootModule with JavaModule {
  def mainClass = "cli.Main"

  object daemon extends RunModule {
    def runClasspath = foo.runClasspath
    def localRunClasspath = foo.localRunClasspath
    def mainClass = "cli.DaemonTool"
  }
}

To preserve binary compatibility, all moved defs retain an override in JavaModule and forward to their super-def in RunModule. Therefore traits compiled against older versions of trait JavaModule should still be runnable with newer versions.

Some run-targets (run, runLocal and runBackground) previously required the compile target, since that also provided some zinc analysis which included some main class discovery. Since the goal was to decouple the run targets from the concept of compilation, I implemented a different discovery logic for main classes which uses the Scala API of scalap. This is completely newly written code but it's only a couple of lines and all existing tests (which also include main class discovery) succeeded. The advantage of the new logic is, that it should work with any given classpath and also for non-Scala classes. The new code is located in the zinc worker, since this is already shared between all RunModules, but there is no real need to have it there. To avoid increased complexity, I resisted to introduce a new shared worker just for the sake of technical independence, for now. The new allLocalMainClasses target can be used to find all main classes in the localRunClasspath. This is some useful information I needed now and then in projects, so it makes sense to have it in a dedicated target for better caching and easy showing.

I also introduced a new localRunClasspath target which abstracts away the classpath that is supposed to be produced by compilation. This is somewhat analogue to the testClassapth introdcued in PR #3064. Since both typically hold the same classpath, testClasspath by default uses the result of localRunClasspath. We probably could remove testClasspath altogether, but it's semantically bound to TestModule and isn't necessarily the same as localRunClasspath, so I think it's legit to keep it.

For consistency, I also added a localCompileClasspath which resembles the part of the localClasspath which is feed into the compiler. All added classpath targets also have a version for BSP (named with prefix bsp and returning a T[Agg[UnresolvedPath]]) when appropriate.

Depends on

• Restructure TestModule, add RunModule  #3064

[lefou]

This is good for a review. @lihaoyi @lolgab