This is slightly simpler, if there's not some reason I'm missing to do
this as it was previously done. And in particular provides a cleaner
API (if we wanted to move this to Smithay; perhaps without the Cosmic
extension).
But it also should be more correct. Presumably if a client (unusually)
had multiple components with their own `ext_workspace_manager_v1`
instance, they should have their own queues, and
`ext_workspace_manager_v1::commit` should be independent.
Inevitably, there's a racy element to multiple components trying to
update the workspace state like this, but it should behave the same as
two clients with separate connections.
(This is different from `CompositorClientState`, since the commit queue
there is fundamentally tied to the client, and different components with
their own compositor instance way have related surfaces.)
It seems at least with Rust 1.82 (the version in `rust-toolchain.toml`)
these bounds are inferred from the `D: WorkspaceHandler` bound, so they
can be specified only there.
Clients have been updated to use ext-workspace-v1 and
cosmic-workspace-v2.
Removing this should save some duplication of having to update both
cosmic workspace v1 and ext workspace code, and should help with things
like using the same workspace handle when a workspace moves to a
different group (which is something that was changed before the final
version of the ext-workspace-v1 protocol.)
If two displays have the same edid (which shouldn't happen, since edid
includes a serial number, but is somewhat common in practice with
identical monitors), match output stack by comparing both edid and
connector name.
If we get the same edid but a different connector, `set_output`
truncates but also adds the new one. (Before adding edid matching, this
would have just added to the output stack.)
`prefers_output()` will requrire a connector name match if the edid of
the current output is the same as that of the output being compared.
If the user explicitly moves a workspace to an output, assume that is
where the user wants it, so it shouldn't be moved back to a different
output in the future.
For persistent workspaces, the explicitly set workspace is the one that
will be stored, instead of trying to track an unbounded list of outputs
persistently.
