Improve handling of qualified names when renaming

[toinehartman]

• Support renaming fully qualified modules names (instead of last name segment only)
• Reject renaming of modules from qualified declaration names.
• Explicitly do not support external imports
• Support module renames from explorer view.
• Escape name segments (\syntax) and v.v.
• Resolve module names via dependencies
• Use 'did rename' instead of 'will rename' callback, to prevent problems in case the evaluator is locked
• Add UI test for module move
• Change qualified names on folder rename

[DavyLandman]

Looks good, with some exceptions that I marked down.

[DavyLandman]

Some small changes, looks mostly fine 👍🏼

[DavyLandman]

Looks good, 2 points that we should still pay attention to:

1. the work inside the eval closure should really only call the evaluator, nothing more (just to avoid deadlocks), I've left a comment where it's happening.
2. the test currently fails.

[DavyLandman]

Some minor comments, but looks good. Also thinks @sungshik for the help with the UI tests.

[DavyLandman]

@toinehartman looks like it's ready to merge, want to do the honors?

[toinehartman]

Just before the holidays, I found there is still an issue remaining with this. A module rename from an editor triggers a move of a module, among other changes. That move than triggers the rename 'from the explorer' (that this PR implements). The latter then produces some edits which are applied after the edits from the from-editor rename, resulting in faulty qualified names.

I switched around the order of the edits that a rename from editor produces in an attempt to reduce this - apply the edits, first, and moves later. For some simple examples, that seems to work, but it's not a robust solution. It seems that versioned edits would get rid of this issue somewhat, although the race for which is applied first, might still be a problem there.

I'll investigate a bit more.

[toinehartman]

After off-line discussion, we reasoned that the issue is mostly solved by reordering the edits that renamings produce. Some async behaviour will remaing due to the nature of the LSP, and is acceptable. Merging.

[sonarqubecloud]

Quality Gate passed

Issues
8 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud