This is more reliable than assuming the link carries the id of its nodes, as there have been cases where a link was created without those
properties set.
Instead, we can just pull them from the state via the port ids of the link.
Glib MainContext is now aquired manually because a change in gtk-rs would lead to
a panic when attaching the receiver otherwise, because gtk::init() doesn't
"leak" the default main context anymore.
This extends the `Application` struct to keep more advanced state.
This state is then used to determine the needed information to create
or delete a link between the two connected ports.
A message to create/delete the link is then send to the pipewire thread,
which executed the request.
The `View` sturct was mostly a layer of indirection, and the controller benefitted by absorbing the gtk::Application
subclass parts, so now those two are merged into a new gtk::Application subclass.
The pipewire loop now runs without interruption in a second thread and communicates with
the GTK thread via a channel in each direction, instead of checking for events once a second and using callbacks.
This allows changes to appear instantly in the view, instead of having to wait.
struct PipewireConnection is now decoupled from any other components, another component (the controller)
can receive updates by registering a callback.
struct PipewireState has been refactored to a struct Controller.
It still keeps state and manages the view, but now also actively requests updates from the pipewire connection via callback.
