Fixes #3761

• Introduce runModuleDeps, the runtime version of moduleDeps and compileModuleDeps

• We introduce transitiveRunIvyDeps, the runtime version of transitiveIvyDeps, and use it in most places as a replacement for runIvyDeps

• I also flipped the ordering of transitiveModuleDeps/transitiveRunModuleDeps to put this on the right/last, to follow the rest of the module resolution logic where "upstream" things come on the left/first in the classpath ordering

There are some behavioral changes, e.g. the A module's direct compileModuleDeps no longer end up on your runClasspath, as shown by the change in the test case mill.scalalib.ScalaMultiModuleClasspathsTests.modCompile. I think the new behavior is more correct than the old one?

One (benign?) consequence of this change is that the contents of the various *run* tasks now have considerable overlap with the non-run tasks, e.g. transitiveRunIvyDeps overlaps with transitiveIvyDeps.

The way transitive runtime dependencies are now managed, both "run{Module,Ivy}Dep of {module,ivy}Dep" and "{module,ivy}Dep of run{Module,Ivy}Dep" are both aggregated into the run classpath. I'm not sure if this matches what Maven does (it does according to chatgpt!) but it seems reasonable to me

Added some additional unit tests to cover the new transitive behavior. The whole dependency-wiring stuff is pretty gnarly but hopefully the existing test suite will stop us from breaking too much (especially mill.scalalib.ScalaMultiModuleClasspathsTests which is pretty rigorous and we add to).

This is a binary-compatible but semantically incompatible change, would be good to get it into 0.12.0

Best reviewed with Hide Whitespace enabled