Update serverSetup.ts

[GitMensch]

• cleanup possibly broken vscode-server.tar.gz
• check for uname (see NixOS not detected as Linux distro #7)

[GitMensch]

I've got into some bad "can not connect, download isn't redone" scenario which is solved by the first part. As an alternative for the second case (extracting does not work) we could output the full path instead of deletion, but I think "drop it if it doesn't work" option is good enough.

[GitMensch]

As I now could reproduce the issue again (after each update) I see that the fix ("applied it manually" by deleting the file, then restarting the vscode window connected to WSL) I see another one that also applies to the open-ssh extension: if you are on Windows and use the "restart for update" option both have the same issue:

• open two or more WSL workspaces to the same WSL instance in parallel
• open two or more OpenSSH workspaces on the same target in parallel

when you now update and restart, those workspaces are opened directly after the start in parallel, the ones that connect to the same machine all find the server directory not being available - and then trying to download the reh file to the same place - the second one seems to interrupt the first one and you end with an invalid target file.

It could be useful to use a synchronization file to work around the race condition here.
... but even then this PR will provide a "works after the first click" until this is done and may fix other similar issues.

[GitMensch]

friendly ping @jeanp413 - the issue happens after each change to the DISTRO_VERSION/DISTRO_COMMIT (=each necessary REH update) and would be changed with this PR (similar changes needed to Open Remote - SSH) to work without manual deletion on the target (which is especially bad when connecting via vscode is the main way to connect...)