With this patch applied, the DemoRunner should build under MinGW, and be
(nearly) feature-complete compared to the MSVC build.

Specifically, when building with MinGW:
- Adds support for accessibility
- Fixes build issues in the juce_video module
- Fixes a link issue in the VST3 wrapper when VST3_CAN_REPLACE_VST2 is
  defined
- Adds support for the new-style native FileChooser
- Tidies up some other low-severity warnings

Known issues:
- Direct2D rendering is still not supported when building with MinGW due
  to ABI compatibilities.

This fixes warnings that are emitted when building with the `-analyze`
flag enabled.

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.

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 change affects the PostVista version of the Windows FileChooser.

The Win32NativeFileChooser was taking ownership of itself
in its `Thread::run` implementation. This meant that sometimes
the destructor of the file chooser thread would execute directly
in `Thread::run`.

Now, we explicitly transfer ownership into a function object which
will run asynchronously on the main thread. This way, the file chooser
thread will be stopped on the main thread.