[Proposal] Add option to specify language server DLL local to yarn project.

[MHDante]

Description:

Allows loading a language server DLL from a location in VSCode settings, overridable per user computer/workspace.

It has been tested to work with multi-root workspaces, in which case the setting must be set once per workspace (since YS-VSC run a single language server for the whole workspace)

Additional changes in this PR:

1. The behavior of the LANGUAGESERVER_DLL_PATH env var usage is updated to allow for absolute paths.
   • This has been tested to still support paths relative to the extension folder.
2. In the case of not finding a dll at the path, the expected absolute path is printed as an error in the console.
   • However, telemetry is provided with either a relative path, or Custom in the circumstance that the user provides a local DLL. This is done to avoid sending out user information in file paths.

Motivation:

As a developer working with a writing team, I'd like to provide yarn language extensions to my team. This extension allows me to ship these changes as a DLL relative to the yarn project, and limits the influence of these changes to only the project to which they are local, preventing it from interfering with the writer's other yarn projects.

As a developer looking to work on language server extensions, I'd like to test changes to the language server in specific test projects without interfering with my day-to-day work on yarn in the main branch.

This setting could allow clients to easily test new language features (such as V3 changes) without requiring a separate branch of the extension (non-lsp grammar updates excluded)

Costs:

• This setting arguably introduces a dependency on DLL-based language servers. If that model changes, it may require user communication on how to upgrade. However, this is not unlike other language server plugins built in dotnet.

• This setting allows for execution of arbitrary .NET DLLs specified in the settings on project load. However, this is consistent with VSCode's trust model, and does not conflict with YarnSpinner's current trust model (@workspaceUnsupported). A user with the C# extension is subject to the same risk.

Alternatives:

It is possible to continue using ENV var to fetch DLL, and ask my writers to switch it on and off when working on this project. This adds complexity to their user experience, and adds onboarding costs.

It might be possible to add the extensions as separate VSCode extensions. However, this would require duplicating the overhead of parsing the syntax tree or using LSP features that are unsupported by the YS language server. Such an approach would also be limited from participating in language server actions such as graph construction or extraction. See here. For more info.

---

As it stands, this proposal allows a minimal but highly flexible way to extend support for yarn language extensions in the VSCode extension.