Fix `acton sig` dependency resolution

[plajjan]

Use mylib.lib for root dependency signatures

acton sig does not currently apply the dependency-root lib alias used for imports: resolveSigTarget looks up the requested target directly in sigModuleIndex, and that index records a dependency's src/lib.act as mylib.lib, not mylib. As written, users following this new example (and the analogous acton sig directory.Contact text in the troubleshooting page) will get a module/name lookup failure for public names defined in src/lib.act; document acton sig mylib.lib / mylib.lib.Name unless the CLI resolver is changed to add the same alias.

Originally posted by @chatgpt-codex-connector[bot] in #2932 (comment)

[nordlander]

I think this is a dubious improvement. We've concluded that in a project proj that contains source files proj.act and lib.act, the module name proj is ambiguous (it could both denote an unqualified reference to the first source, and a qualified and aliased reference to the second one). For that reason we decided that the --root command-line argument never accepts project-qualified module names, which is a reasonable restriction when it comes to building binaries.

For the acton sig command the perspective is slightly different, but the ambiguity problem remains the same. So what should acton sig proj do in the project outlined above? Use some built-in priority to decide which interpretation wins? Or simply complain and ask the user for an unambigues naming alternative (like proj.proj or proj.lib)?

[plajjan]

@nordlander I think you are talking about local resolution of src/lib.act, right? I think this issue is for a dependency project, so the root project has a dependency on mylib and in mylib there is a src/lib.act which we should then be able to do acton sig mylib on to get its entire type interface - right now I don't think it works, or so the bot would have us believe..

[nordlander]

Indeed, for dependencies the case is much simpler, I agree we ahould fix the lib alias for those. But for the local project the most conssistent thing must be to refer to src/lib.act simply as lib, especially if we also remove the ability to project-prefix local modules altogether. And with Marcos fix of the various module name printouts I don’t think there’s much to ponder. I’ll get to it in the morning.

(One thing that also remains is to drop the local project from import listings in the acton sig printout. And I can’t deny there’s something deeply unsatisfactory about adding these prefixes at various places, just to have them dropped before the user ever gets to see them. But the villain behind all this is my old decision to have all types names unaliased before the type-checker starts its unification attempts. Now imagine if we could compare type names using unique integer ids instead…)