Rethink ModuleIdentity #288
Description
This class is old, and today it serves several purposes with short-sighted assumptions. It's unclear what an instance even identifies. The same module source can be instantiated multiple times in different registries (like inside a sandbox), so this doesn't identify module instances. It's also insufficient to identify code, which is why ModuleLocation is a separate class. And I have a longer-term design goal that paths can be remapped within an evaluation context, for example the deployer could substitute an implementation of some library code.
At present, I think ModuleIdentity needs refactoring into something more like ModulePath (if we can't just use Path) because that's the main use case. A better implementation might be a chain of components/names, so we can access parents and construct children with fewer allocations and minimal String manipulation. We also need to support relative paths somehow, and currently that's handled via Strings, which is weak modeling.