RDP/VNC: Ensure PipeWire buffers to be queued before destroying them

The commit message for both the RDP and VNC backend is the same:

When the stream resolution changes or the stream is destroyed, PipeWire
will destroy all buffers for that stream.
Before destroying a buffer though, the remove_buffer callback is called.
This is very useful, because when a stream resolution change happens may
not always be predictable, and currently gnome-remote-desktop crashes,
when it processes a buffer in the EGL thread while it is destroyed.

To solve that crash, register for each PipeWire buffer a buffer context.
That buffer contains a mutex, which is locked, when the respective
buffer data needs to be processed in the EGL thread.
When the buffer data was processed, the mutex is unlocked again, if it
was locked before.
When destroying the buffer context, that same mutex is locked and
unlocked again.
If the buffer is about to be destroyed and the EGL thread still
processes it, that lock operation in the destroy function will wait for
the EGL thread, ensuring that no data, that is currently  in use, is
destroyed.

This should (hopefully) handle https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3040. I talked to Wim on IRC/Matrix and this scenario might be the cause here, at least we currently don't protect against it.
Before a PipeWire buffer is destroyed, PW calls the remove_buffer callback, and if we block here, the destroy operation is postponed, since in that function the buffer is still valid (until it returns).