decouple getters from setters

[dnut]

While working on #4, I realized hybrid clipboards may not even be needed. Maybe there's a better more flexible design for this service. Keep a vec of all getter clipboards and all setter clipboards. Monitor getter.get() for each getter, and if there's a change, set it for every setter. There's no need for a hybrid clipboard because you don't need to link a display's input channel with its output channel.

Why is this advantageous? Doesn't it just make it harder to understand what's happening to a single display when it's split in multiple places? Yes but that may be unavoidable to an extent. It may be too hard to even identify what constitutes both the getter and setter for a single display, especially if there are x11 displays with their own display numbers that don't correspond directly to a wayland display number, meanwhile you need to use the x11 clipboard to connect to a gnome wayland getter.

Maybe it makes more sense to simply figure out anything you can plug into as either an input or an output, agnostic of whether there's a display that associates some input with some output. Accept updates from anywhere, regardless of whether you think there's some input associated with it. Broadcast updates to anywhere, regardless of whether you think there's some output associated with it.

[dnut]

bbac459

I came up with a compromise approach that still links inputs to outputs but doesn't bother trying to hybridize displays. It just finds all the x11 and wayland displays using the standard approaches to access those displays without any fancy attempts to create hybrids that work for known specific displays like mutter. So far this looks good enough because if a wayland compositor does not support the wayland standard, it seems to support the x11 clipboard. Treating mutter as x11 works just as well as treating it as a hybrid (or possibly better since calling the wl-paste cli has some weird behaviors).

This is slightly less flexible than the proposed solution because it can't handle these situations:

1. a display only works with inputs from one implementation and outputs from another implementation,
2. either a getter or setter exists on its own without any known complement

1 should be doable but it is more complicated so I didn't bother with it yet. I'll leave this issue open to address that approach later.

2 might actually be the easiest approach if you just ignore how any displays are linked together, but that's not optimal because you end up with duplicates. So there should at least be some round of optimization that checks for linkages between inputs and outputs and checks for duplicate representations of displays.

Then there's a question for 2, whether we should be including getters and setters that can be instantiated and called without error, even if they don't appear to be connected to any complementary setter or getter. Would there ever be a real clipboard that has this pattern? Or is it more likely that we'd just be calling useless functions that simply return because the library designer decided to return Ok(()) even if the clipboard doesn't exist? This could actually result in monitoring hundreds of imaginary clipboards that don't exist when there are only a couple clipboards on the machine. So I'm inclined not to include this feature unless there is a known concrete benefit.