[rdp,vnc]-pipewire-stream: Lock buffer mutex before removing buffer entry

Quoting the commit message:

g_hash_table_remove first removes the hash table entry and then frees
the key and value with their respective destroy function.
This is problematic, since when PipeWire tries to destroy a buffer it is
supposed to wait until it is queued again, but when the hash table entry
is already gone, the main thread waits indefinitely and the EGL thread
hits an assertion, since the buffer is not tracked any more in the hash
table.

Fix this issue by looking up the buffer first, then lock its mutex,
unlock its mutex, and then remove the hash table entry.

Ran into this assertion with a virtual monitor stream.

@jadahl We need to backport this for 44.2, since the buffer_context thingy is also in 44.x.