Previously, once 'm_aContents' had been assigned in
'VclQt5Clipboard::setContents()', its value (or the one set
in a subsequent call to the same method) was always
returned in 'VclQt5Clipboard::getContents()', thus
ignoring all system clipboard updates done by any other
third-party applications, preventing copy-paste from other
applications.

In order to take external clipboard updates into account,
add a slot for the 'QClipboard::changed' signal and
drop the current own clipboard content if the clipboard
has been updated by another application.

In order to detect whether the clipboard update was made
by this 'VclQt5Clipboard' itself or elsewhere, a custom MIME type
"application/x-libreoffice-clipboard-uuid" is added, whose
value is set to the clipboard's (randomly generated) UUID.
If the entry is present and has the correct value, the clipboard
content was added by this clipboard and can be kept.

Otherwise, clear 'm_aContents', so that it's newly assigned
in 'VclQt5Clipboard::getContents()', taking into account
the external clipboard update.

[Side note: Testing showed that, on Wayland, more
'QClipboard::changed' events were emitted without the clipboard
content actually having changed (e.g. when switching focus between
windows), which is why an approach of simply setting a flag and
checking for that one is not enough, like "wrapping" the
'QClipboard::setMimeData()' call in 'VclQt5Clipboard::setContents()'
as follows

    m_bIsFillingClipboard = true;
    clipboard->setMimeData(pMimeData.release(), m_aClipboardMode);
    m_bIsFillingClipboard = false;

and then evaluating the 'm_bIsfillingClipboard' flag in
'VclQt5Clipboard::handleClipboardChange' instead of using the UUID-based
approach. These additional 'QClipboard::changed' events did not
show up the same way while testing on X11.]

Change-Id: Ib3a6a4f9b7f5ca3573666fb9c072ae97cf2e0049
Reviewed-on: https://gerrit.libreoffice.org/68214
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>