RDP/VNC: Stop dequeuing PipeWire buffers while destroying the stream

Quoting the main commit here:

When destroying a PipeWire stream, gnome-remote-desktop needs to handle
two cases:

1. Ensure, that all PipeWire buffers have been processed by the EGL
   thread.
2. Ensure, that while waiting on the EGL thread, no new buffers are
   queued onto the EGL thread.

This was initially done with a helper variable and a call to
pw_stream_flush, which mostly solved the situation, but not always.
When audio output forwarding was implemented, it was discovered, that
setting a PipeWire stream inactive seems to wait for the PipeWire data
thread, as the PipeWire data thread in audio streams was waiting for a
mutex to be released, and the inactive call did only return, when that
mutex was unlocked.
As a result, the old mechanic during the stream destruction was
replaced by setting the PipeWire stream inactive.
However, regardless of this, there are still crash reports in both
Fedora retrace and Ubuntu errors.

It appears, with some help in reproduction using GConds and g_usleep(),
that setting a PipeWire stream inactive, does not wait for the data
thread to end its iteration.
This is at least true for any screencast stream.

So, to finally fix this situation, do not rely on any PipeWire methods
any more.
Instead, introduce, like initially done, a helper variable, that tells
the PipeWire data thread to not dequeue any buffers any more.
However, instead of flushing the stream, pair the helper variable with
a mutex.
The PipeWire data thread will lock the mutex during its whole
operation, while the main thread only locks it to set the helper
variable.

This partly reverts 4303a4f5f42689012bc87f74e9fca16813c3dee0.

Kinda weird: One other approach, that I tried, was to perform a roundtrip after setting the stream inactive.
But even after that roundtrip, the data thread still got called.