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 lib/vscode build/gulpfile.reh.ts, the
   platform === 'win32' arm: rename(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 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 it was 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.