Document and test workflow for aliasing external modules

[lihaoyi]

Fixes #299

I'm a bit surprised that this just works, but it does!

The module's millSourcePath and out/ folder path remain at their original locations as the mill.define.Ctx is still provided by the top-level ExternalModule constructor, it's just during resolution the added method def allows it to get picked up during object graph traversal

[lefou]

• I think the solution space for Storing module reference in module causes resolve to stack overflow (500USD Bounty) #3715 is pretty identical to the effect you exploit here. If we find a way to detect, whether the rhs has already an Ctx and is assiciated with a instantiated module, we just need to provide an additional name for it, but not re-instantiate a new module.

[lihaoyi]

I think #3715 is kind of adjacent, since it's more about preventing the stackoverflow. Whether the referenced module ends up discoverable or not isn't the main issue raised in that ticket, although it's certainly worth discussing.

One potential issue with def aliases is that one module can now have different selectors turn up when you resolve _. For external modules that's not a big deal since the external module namespace and internal module namespace are kept separate, but once you start aliasing internal modules then the duplication occurs. Even in scenarios without infinite loops, when someone does a mill resolve __ we probably don't want to "expand out" every module alias and print a huge wide tree when it may actually just be a relatively narrow DAG