spawn now requires that the window_id be passed in; this makes it
a bit easier to spawn a remote tab into an existing window.
As part of this, beef up how we manage the window/tab association.
The Domain::spawn interface needs to be adjusted to allow indicating
which window we want to spawn into, or whether the spawn should
create a new window, but aside from that, we can now attach to
a mux server and instantiate tabs and windows!
The client domain stuff is now what I'd describe as almost
basically functional. It's not a great experience because
the latency is a bit high (it uses the coarse render data
as a proof of concept, and polls that every 100ms), and doesn't
connect the clipboard to the remote session. It also doesn't
enumerate and instantiate tabs for existing tabs on the remote
server, and doesn't have a way to gracefully detach from the
remote.
However, it is possible to connect and spawn tabs and interact
with them.
This removes some awkwardness in the impl by allowing casting
to a concrete implementation. This is a pattern I want to use
more widely and this diff proves the concept.
The idea is that we can use this to spawn a tab in a
specific domain. For example, "spawn tab in domain of current tab"
or "spawn tab in default domain".
Usage example is to put this in your `wezterm.toml` to get the
macOS CMD-M shortcut for minimizing a window:
```
[[keys]]
key = "m"
mods = "CMD"
action = "Hide"
```
Refs: https://github.com/wez/wezterm/issues/32
This was blocked by some awkwardness in figuring out which
gui frontend was in use and queueing up the spawn and then
more ugliness in glutin.
That has subsequently been sorted out with the newer executor
stuff, so cut this over.
This is a tiny baby step towards a bigger key binding config
and thus refs: https://github.com/wez/wezterm/issues/32
