Fix the windows arms of the release build scripts

[denusklo]

Every hunk here is in a branch only windows takes, and windows has never built a release, so none of them has ever run. They are what stands between OS=windows npm run release and a tarball. Nothing off windows changes: the first two are inside a windows-only case, the third adds a test around a copy, the fourth excludes a file no other platform has, and the fifth adds windows to a condition it was missing from.

1. The remote-cli launcher is named after product.applicationName, which this repository overrides to code-server, so what gulp writes is remote-cli/code-server.cmd. The windows arm asked for remote-cli/code.cmd, which is the name of the template it is built from. The posix arm four lines below already spells it code-server. See build/gulpfile.reh.ts in the pinned vscode, the platform === 'win32' arm: it renames to bin/remote-cli/${product.applicationName}.cmd.

2. fix-bin-script rewrites the launcher's root to the release root and then has to send the two things still living in the vscode tree back down again. It does that for out/ on both platforms, and for the node binary only on posix, where the third sed rewrites $ROOT/node to $ROOT/lib/node. The windows half had no counterpart, so the .cmd launchers looked for node.exe at the release root while build-release.sh puts it in lib. NODE_EXEC_PATH, which the posix rewrite also honours, has no equivalent on this side and is not invented here.

3. The node binary is called node.exe on windows (gulpfile.reh.ts renames it in the same win32 arm as above), so this copy asked for a file that is not there and took the whole release step down with it under set -e.

4. The same name again, in the exclusion that keeps node out of lib/vscode because it belongs one directory above. /node does not match node.exe, so on windows the binary was copied into lib/vscode as well as being placed above it.

5. build-packages.sh renames the tree's top directory as it archives, and reaches for bsdtar's -s off linux because that is what macos has. The bsdtar windows ships is built without substitution support: it answers "-s is not supported by this version of bsdtar" and its --help lists no such option. So windows belongs on the GNU --transform arm. Checked against both, bsdtar 3.7.7 and GNU tar 1.34.

Verified by building a windows release with these applied and then running what came out: the server serves, the extension host starts, and a terminal in the workbench round-trips a command. For hunk 2 specifically, the built launcher reads call "%ROOT_DIR%\lib\node.exe" ... with ROOT_DIR at the release root, and node is at lib/node.exe. Running it reaches node and gets server-cli.js's own "only available in WSL or inside a Visual Studio Code terminal", exit 0. Putting that one path back the way upstream has it gives '...\remote-cli\..\..\..\..\node.exe' is not recognized, exit 1. What is not covered is the launcher's later behaviour against a live server, which needs VSCODE_IPC_HOOK_CLI set by a workbench terminal.