LSP gets module versioning slightly wrong

[cuematthew]

Currently, on the first load of a cue file, we'll find the module root, and that cue file's package, and we'll issue one call to modpkgload. This single call loads the whole graph of required modules and packages, solving MVS. We take those results and create Modules and Packages within the LSP. Packages belong to Modules, and Modules are considered unique by the path to their root folder. This allows for sharing: if you have two modules A and B, and they both depend on the same version of C (which will be from CUE_CACHE_DIR) then we'll only have one copy of C in memory and it'll be used by both A and B.

However. Consider:

• A and B and C all depend on module D.
• A uses D version 1.2.
• B uses D version 1.3.
• C uses D version 1.1.

If the user opens a pkg within A first, and then B, then the act of opening B will cause the graph of B, C and D to be constructed, MVS solved, and modules+pkgs loaded. This will result in C now using D version 1.3. Thus C's path hasn't changed, but its imports have. By loading B, we've accidentally changed the version of D that A is using.

I think the modelling of modules needs to change within the LSP.

1. A module is unique not by its path-to-root alone, but by a (path, loadingModule) tuple, where the loadingModule is the "main" module that caused it to be loaded (graph root?).
2. If a package becomes dirty, you can't reload that package in isolation. You actually need to go back to the loadingModule and reload everything from there.

There are some fun "impossibilities" to think about here. Let's say the user has a file open which is in a pkg in C. And let's say we fix the above so that an edit to this file causes both the whole of (A,C,D) and (B,C,D) to get reloaded, and all the state is managed correctly. Now the user presses "jump to dfn" for some path which resolves to a field in D. Which version of D do we use?!