Add VS Code fork detection & manual .exe selection to "Code Editor" Selection

[wpenistone]

Summary

This PR overhauls the code editor selection system to support manual .exe selection, detection of VSC forks, and improving discovery.

Motivation & Context

Many users now prefer specialized vibe-coding slop generators like the one I am currently using and Cursor, Windsurf, or Trae, there is no user-friendly way to add them and PRs to do so cause more bloat (like 192).
Sometimes people will have random issues and unable to use their existing IDE, letting them choose an .exe is very flexible because of this.
Additionally, portable or user-only installations of these editors often fail auto-detection because they don't register in the standard HKLM registry keys.

• Satisfies: Add Antigravity IDE support #192
• Fixes: Can't specify IDE directory/IDE not found #936
• Fixes: Add support for VS Code Insiders in the editor #3833
• Fixes: Add VSCodium to the Project Preferences #9997

Implementation Details

• Polymorphic editor sensing: Replaces hardcoded string checks in the UI with a method where editor implementations identify if they match a given executable. This makes the system extensible for adding new editors without modifying the core UI widget.
• Tiered installation discovery: Overhauls the location sensing to check manual overrides, application registrations, and both machine-wide (HKLM) and per-user (HKCU) registry entries, improves auto-detection for portable or user-only installations.
• ux & bloat:
  • Manual override appears as an item in the dropdown and disappears when the user unselects it. (see screenshots)
  • To avoid list bloat VSC forks are automatically hidden from the main list unless they are detected.
• Unified VS Code integration: Consolidates the launch and detection logic for VS Code-based editors into a shared base class, enabling support for diverse forks (Cursor, Windsurf, Trae, etc.) in just 3 lines with consistent argument handling.
• Browse for .exe: Assumes VS Code fork (or same format as it) if it can't find a name match.
  [I guess we don't "need" handling for VSC forks if they can just browse for it? nah good UX nevertheless]

Screenshots / Videos (if applicable)

Checklist

• Code follows existing style and conventions
• No unnecessary formatting or unrelated changes
• Public APIs are documented (if applicable)
• Unit tests added where applicable and all passing
• I’m okay with this PR being rejected or requested to change 🙂
• Add padding to the button

[Copilot]

Pull request overview

Updates the editor selection/preferences UI and editor integration layer to better detect VS Code forks and allow users to manually map an editor executable when auto-detection fails (esp. non-HKLM installs).

Changes:

• Refactors VS Code integration into a shared VSCodeBase with registry/app-path discovery + manual override support.
• Enhances the “Code Editor” selection widget to sort by install status, hide undetected VS Code forks, and add a “Browse for .exe” action.
• Adds executable-name matching helpers for Rider/VS/VSCode-based editors and adds Rider manual override support.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 9 comments.

File	Description
game/addons/tools/Code/CodeEditors/CodeEditorControlWidget.cs	Rebuilds the code editor dropdown behavior and adds manual executable browsing/mapping.
game/addons/tools/Code/CodeEditors/CodeEditor.VSCode.cs	Introduces VSCodeBase, adds fork classes, improves discovery, caching, and launch behavior.
game/addons/tools/Code/CodeEditors/CodeEditor.Rider.cs	Adds Rider exe matching and a cookie-based manual path override.
game/addons/tools/Code/CodeEditors/CodeEditor.VisualStudio.cs	Adds Visual Studio exe matching helper.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[trulybeardless]

I would like to make two UI/UX suggestions.

These relate both to the current implementation as well as your additions.

First, the button seems to be slightly misaligned (though that might just be the screenshot).

And secondly:
Currently, if the engine does not find an editor, it appears just the same as one that was found in the dropdown.
The only noticeable change is... well, you can't press 'em (I honestly thought this was a bug the first time i tried to select one).

Greying out the button doesn't seem to be a good option, since the dropdown's already kind of greyed out. I believe the distinction would be too minimal.

Making the not-found editors title cursive might work. Alternatively, a Toast or Popup with a warning would also give user feedback as to 'why the hell this darn button ain't working'.
Maybe both?

[wpenistone]

I would like to make two UI/UX suggestions.

These relate both to the current implementation as well as your additions.

First, the button seems to be slightly misaligned (though that might just be the screenshot).

And secondly:
Currently, if the engine does not find an editor, it appears just the same as one that was found in the dropdown.
The only noticeable change is... well, you can't press 'em (I honestly thought this was a bug the first time i tried to select one).

Greying out the button doesn't seem to be a good option, since the dropdown's already kind of greyed out. I believe the distinction would be too minimal.

Making the not-found editors title cursive might work. Alternatively, a Toast or Popup with a warning would also give user feedback as to 'why the hell this darn button ain't working'.
Maybe both?

Yes I agree, the browse button has no right padding and the combo box options don't differentiate between greyed out, someone from s&box maybe can answer why this happens (I am just using them, nothing custom) or I'll have a seperate PR fixing them if this seems to be unrelated.

[trulybeardless]

I would like to make two UI/UX suggestions.
These relate both to the current implementation as well as your additions.
First, the button seems to be slightly misaligned (though that might just be the screenshot).
And secondly:
Currently, if the engine does not find an editor, it appears just the same as one that was found in the dropdown.
The only noticeable change is... well, you can't press 'em (I honestly thought this was a bug the first time i tried to select one).
Greying out the button doesn't seem to be a good option, since the dropdown's already kind of greyed out. I believe the distinction would be too minimal.
Making the not-found editors title cursive might work. Alternatively, a Toast or Popup with a warning would also give user feedback as to 'why the hell this darn button ain't working'.
Maybe both?

Yes I agree, the browse button has no right padding and the combo box options don't differentiate between greyed out, someone from s&box maybe can answer why this happens (I am just using them, nothing custom) or I'll have a seperate PR fixing them if this seems to be unrelated.

Ah, alright. Thanks for your work!
I might take a look at it as well, wanted to poke around the S&box source for a while now.

[trulybeardless]

Nice button formatting

[trulybeardless]

As per Facepunch:
No hardcoding of Editors, even with the current implementation. The editor detection will be overhauled at some point by FP.