Add support for access any classes via Package Stacking

[ThijsBroersen]

Multi-file builds could be more concise with Package Stacking.
If I now want to use root or parent package object, I have to always import them with the full build.SomeThing path.
Package Stacking is by Mill correctly used as package, but any classes of shared packages are not imported by default.

e.g. taking a modified example from the docs

package build
import $packages._

import mill._, scalalib._

trait MyModule extends ScalaModule {
  def scalaVersion = "2.13.11"
}

package build
package foo
import mill._, scalalib._

object `package` extends RootModule with MyModule { // <- Not recognized
  def moduleDeps = Seq(build.bar.qux.mymodule)
  def ivyDeps = Agg(ivy"com.lihaoyi::mainargs:0.4.0")
}

[lefou]

This is a current limitation in our code generator.

Since we need to generate some code under to hood, the build object your using to access build.bar isn't what it seems. Although it looks like your accessing the package build, you effectively accessing the generated build_.package_ object which is imported under the build name. Making the package build explicitly visible probably shadows the later generated import build_.{package_ as build} and results in a build failure.

[lihaoyi]

This worked in the the branch of Mill using referenceable package objects (#4745) but we didn't end up landing that because the feature is still experimental in Scala 3.7.x. When it eventually stabilizes and we begin using it, that will allow us to do this

[ThijsBroersen]

I just encountered an issue that when I do 'import build._' in a nested package.mill file, then the module paths are incorrect. The subdir path is totally stripped and it tries to look for the nested module path directly in the root directory of the project.
E.g. ./code/core which contains a package.mill with the import build._ then module and source dir/paths of modules in this nested build file are stripped of the /code/core path. 😕
@lefou this is prob the shadowing you mention. I think it is quite unintuitive behaviour that (I assume implicit/given) values from the build package take precedence of something I do not even define in this module.

[lihaoyi]

@ThijsBroersen please provide a minimized repro we can look at for the import build._ misbehavior and open a new issue

[lefou]

My suspicion is, that this could be related to some of your .mill files using stacked package declarations.

[ThijsBroersen]

Here a small example: https://github.com/ThijsBroersen/mill-multi-file-test

I will open a new issue.

[ThijsBroersen]

fixed by #5345