## Summary

When running the dev version of Zed and trying to connect to a remote
server, Zed triggers a local build of `remote_server` and uploads it to
the remote. When the local host is different from the remote, Zed uses
`cargo-zigbuild` to cross-build the `remote_server` binary. When the
local host is Windows and the remote is a Unix system, it just works,
but in reverse, it does not.

The truth is, I have never been able to cross-build the Windows
`remote_server` binary on my Linux machine; it always throws an error in
the linking stage. Apart from that, even when using some dirty hacks, I
can have the binary built and uploaded, but there are still two
problems:
- the `remote_server` binary size is very big, larger than 1.0 GB
- it is very unstable, always exiting shortly after the connection.
Partly it is because we are cross-building a gnu version binary:

https://github.com/zed-industries/zed/blob/e52ab15eac51e5644da6a3c9e1fac9bb2330b000/crates/remote/src/transport.rs#L293-L307

So in the past, to test if a remote fix works, I needed to first push
the fix, ssh to the remote Windows server, pull the changes, and build
the `remote_server` directly on that Windows machine, then manually copy
the binary to the directory where Zed stores remote servers. Not a fan
of this at all anymore.

So here, instead of using `cargo-zigbuild` to cross-build the Windows
`remote_server` on Unix-like platforms, we change to `cargo-xwin`, which
is designed to cross-build the msvc version of Windows programs from
Unix-like systems. From my local test, it can do the work perfectly, and
the produced binary size is about 200 MB, the same as the binary built
directly on a Windows machine, and more importantly, it is very stable,
with no dropped connections or crashes.

I suspect there are some concerns:
1. When first running `cargo xwin`, some Windows-sdk files are
downloaded and cached.
2. If we need to use `cargo-xwin`, we need to accept the Microsoft
license: https://go.microsoft.com/fwlink/?LinkId=2086102
3. In the final linking process, there are always some warnings,
typically:
```
         lld-link: Cannot use debug info for 'libcmt.lib(dyn_tls_dtor.obj)' [LNK4099]
         >>> failed to load reference 'D:\a\_work\1\s\binaries\amd64ret\lib\amd64\libcmt.amd64.pdb': No such file or directory

         lld-link: Cannot use debug info for 'libcmt.lib(initsect.obj)' [LNK4099]
         >>> failed to load reference 'D:\a\_work\1\s\binaries\amd64ret\lib\amd64\libcmt.amd64.pdb': No such file or directory

         lld-link: Cannot use debug info for 'libvcruntime.lib(softmemtag.obj)' [LNK4099]
         >>> failed to load reference 'D:\a\_work\1\s\binaries\amd64ret\lib\amd64\libvcruntime.amd64.pdb': No such file or directory
```

## Testing

You can just run the following commands on a Linux or Mac machine to
test the `cargo-xwin` build of `remote_server`:
```bash
rustup target add x86_64-pc-windows-msvc

cargo install --locked cargo-xwin

cargo xwin build -p remote_server --target x86_64-pc-windows-msvc
```

## Self-review

- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [ ] Tests cover the new or changed behavior.

Release Notes:

- N/A

---------

Co-authored-by: Kirill Bulatov <mail4score@gmail.com>