fix #683 Restore VsCode 1.91 behavior of allowing scripts as executable

[JVApen]

In VsCode 1.72 Node was updated to version 20, before this upgrade, it was possible to execute cmd/bat scripts as executable.

After this update this was suddenly broken.
Our use-case for using such a script has to do with the consistency of our clang-tooling.
We build clang-format, clang-tidy, clangd ... all together and put this in a package manager.
In the script, we first download these executables (when needed) and than start the downloaded clangd.
As such, when fixing an issue in clang-tidy, the same issue will get fixed in the clangd exe.
Without this script, it is impossible to automatically trigger this download and it introduces the risk that we do not update all the tooling to the latest version.

[JVApen]

fixes #683

[HighCommander4]

Looks reasonable to me, using shell: true was recommended by a vscode-languageclient maintainer in microsoft/vscode-languageserver-node#1556 (comment).

I assume the PR title should read "vscode 1.91 behavior" (rather than 1.71)?

Do you know if using shell: true also means that on Unix-like systems, ~ in "clangd.path" or "clangd.arguments" will now be expanded to the user's home directory?

[JVApen]

@HighCommander4 I don't have a Linux system at hand to test that. Though my understanding of the option is that it enables scripts. Instead of just regular exes. Inside the script, you have access to the env variables.

As such, by using a clangd.sh with ~/clangd $@ should make it possible to use enable it.

[JVApen]

@HighCommander4 What should still happen before this can land?

[HighCommander4]

Do you know if using shell: true also means that on Unix-like systems, ~ in "clangd.path" or "clangd.arguments" will now be expanded to the user's home directory?

I did check on Linux and expansion of ~ does not happen in either "clangd.path" or "clangd.arguments".

It wasn't obvious to me whether that would be the case, because I went digging in the vscode-languageclient source code to see what it does with the shell: true parameter, and found that it forwards it to the nodejs API child_process.spawn, for which the documentation of the parameter says:

runs command inside of a shell

That's a bit vague -- it could well include performing shell expansion of the command / its arguments... but I guess not.

Anyways, I think this patch is fine regardless. I mostly wanted to document these findings for the benefit of anyone in the future who might want to get shell expansion to work or wonders why it doesn't already.