IFileDialog::Show and CoUninitialize both seem to require the main
message loop to be active and running when they are called. If we block
the message thread while calling these functions, we may cause a
deadlock.

The destructor of the Win32NativeFileChooser was blocking the message
thread until the background thread exited, but the background thread was
unable to make progress while the message thread was blocked.

To work around this issue, we now pump the message thread in the
destructor of the Win32NativeFileChooser. If a dialog is currently
active, this should allow it to exit gracefully.

Note that we cannot use MessageManager::runDispatchLoopUntil here:
- MessageManager::runDispatchLoopUntil will not process any messages if
  the quit message has been received, which could lead to deadlocks if the
  FileChooser is destroyed after the quit message has been posted.
- This function isn't defined when JUCE_MODAL_LOOPS_PERMITTED is disabled.

As specified in https://specifications.freedesktop.org/clipboards-spec/clipboards-latest.txt, CLIPBOARD should be used for explicit cut/copy/paste operations over PRIMARY

This resolves an issue on macOS Catalina when using
JUCE_COREGRAPHICS_DRAW_ASYNC where windows would sometimes fail to
completely repaint when they were unminimized.

Ardour seems to listen to the bounds of the plugin window, and will call
`onSize` on the plugin editor when move/resize events are sent to the X
window - even if the size of the window didn't really change. This can
result in an infinite resize loop, where calling `onSize` on the VST3
instance sends a resize event to the plugin window, and this event
causes Ardour to call `onSize` on the plugin view.

To get around this, the Linux ComponentPeer will no longer request a
bounds change from the window system if the requested bounds are the
same as the current bounds.

Previously, things like PopupMenus which were created in their own
windows were not being scaled correctly on HiDPI displays on Linux.

This patch forces the display scale to 1.0 in plugins, meaning that
the transform applied to the main plugin window is the sole source
of truth for component scaling in plugins.

It seems like shared_from_this may not be enabled when a unique_ptr is
assigned to a shared_ptr (although it *should* be enabled when
constructing a new shared_ptr from a unique_ptr). Functions that return
objects that may need to use shared_from_this now return shared_ptr,
just to be safe.

Additionally, in some cases, shared_from_this was being called from
Thread::run after the last reference to the shared object had been
released. We now call shared_from_this during 'open', which will always
run on the message thread while at least once reference to the shared
object is alive.

This patch should resolve an issue where the popupmenu for a combobox
could become 'stranded' if the plugin window was moved while the box was
open.