LSP: Fix file URI handling + warn about workspace project mismatch

[HolonProduction]

Fixes #103565
Fixes #92248
Fixes #105000

Might have an influence on:
godotengine/godot-vscode-plugin#649
godotengine/godot-vscode-plugin#650

This PR does two things:

• Replaces the file URI handling from the language server with an implementation based on rfc3986 and rfc8089. So that the URI is properly read and decoded.

• Do stuff to convert the absolute URI path to a valid res path, taking into account projects in symlinked directories and case insensitive file systems. This should solve a lot of problems with duplicate class name errors when using the language server.

Also adds a warning if the root location of the workspace does not match the project which is open in Godot.

TODO:

• Test on windows (drive letters might need special handling, since the absolute path from the URI might contain a leading slash before the drive letter. We might need to strip it).

This was only briefly tested on a Windows VM. Further Windows testing might be helpful.

This PR changes the behavior of exposed methods. I'm working under the assumption that the language server is experimental (not the feature, but the exposed API). See #105016

[xelevena]

On Windows 11 10.0.26100
Using MinGW for compiling

On Visual Studio Code tried load a scene from "C:\Users\11650\Desktop".

Inside Godot editor also open the scene file. Both file change at the same time. Did not see bugs regards driving letters.

[Nallebeorn]

Tested this on Windows. I still get the #103565 error about "Hides a global script class" in VS Code, and I see the new warning even when editing the opened project (I launched VS Code from Godot in fact).

get_file_path returns a path like /c:/Users/Name/dev/project-name, just like you said.

[HolonProduction]

Thanks for testing! Sounds a bit like Godot could load such paths, but not make them local to the project. I'll spin up a VM and take a look I guess.

[HolonProduction]

The actual hard part wasn't the leading slash, but dealing with the case insensitive file system. I made some adjustments so that paths should now be correctly mapped to the casing with which they are known to Godot. I did some basic testing in a VM but another round of testing by actual windows users would be appreciated.

[HolonProduction]

I'll mark this as ready for review since I'm done on the code side of things, and my limited testing seemed to work.

[resty-daze]

This is working in my project under windows and resolved the annoying error using vscode. Thanks for your work

[kitbdev]

Tested on Windows, works fine for the most part. I couldn't reproduce 'Hides a global script class' errors, but the others are fixed. This also fixes using certain symbols in filenames.

I don't know much about the EditorFileSystem, but it uses threads itself and EditorHelp seems to use parts of it in a thread, so it is probably fine.

[HolonProduction]

I couldn't reproduce 'Hides a global script class' errors, but the others are fixed.

I think I was able to reproduce this, by checking the paths which VSCode sends and then opening Godot via CMD at the same path but with a different capitalization of the drive letter.

[Repiteo]

Thanks!