The bug was triggered on Monterey where a pressure of 1 is reported
while a mouse button is being held down. This caused an extra drag
event being triggered between mouse down and up events, even if no
movement occurred.

This change is intended to resolve an issue where iOS apps failed
automated review due to use of non-public selectors. Explicitly adopting
the relevant protocols allowed an app to pass automated review during
testing.

This change is intended to resolve an issue where iOS apps failed
automated review due to use of non-public selectors. Explicitly adopting
the relevant protocols allowed an app to pass automated review during
testing.

This issue affected windows with JUCE titlebars. When dragging the
window back and forth between two displays with different DPI settings,
the window could sometimes end up with the wrong size.

It looks like setting new window bounds inside the WM_WINDOWPOSCHANGED
message was occasionally causing the system to lose track of the correct
scale for the window.

As a byproduct of this change, JUCE should no longer receive reentrant
calls to handleDPIChanging.

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.

Effects of this change for windows with native titlebars:
- Resizable windows without maximise buttons will now only allow the
  'zoom' behaviour from the rightmost titlebar button (i.e. this button
  will not allow entering full-screen mode)
- Non-resizable windows will grey-out the rightmost titlebar button,
  whether or not the maximise button is enabled

This works around a rare issue in the DialogsDemo where the AlertWindow
would fail to display because no peer had focus.

When FileChooser instances were created, launched, and hidden all inside
the same event callback on macOS 12.0.1, the chooser dialog sometimes
remained open. This could cause problems including crashes, as closing
the dialog would attempt to call a completion handler block referencing
an already-deleted FileChooser::Native instance.

Opening the chooser panel later on the message thread seems to resolve
the issue.

This mirrors the behaviour on Linux, where maximizing a window always
fills the screen, even if a constrainer is active.

If you don't want to allow your component to fill the screen, disable
the maximize button in the window's titlebar when creating the window
(i.e. ensure DocumentWindow::maximiseButton is not set in the required
buttons).