The following was observed for a VST3 plugin hosted in Live 11.1 with
auto-scaling disabled:

- It never calls setContentScaleFactor on the plugin's UI, so the
  wrapper has to check the current display on a timer and update the
  current scale factor when necessary.

- It calls canResize on the plugin view after opening it, but doesn't
  seem to respect the result of this call. According to the VST3
  documentation, a host is supposed to only call checkSizeConstraint
  during a live resize operation (which should only happen if the plugin
  reports it can resize), but Live calls this function every time the
  user drags the editor. It also passes the result of this function to
  onSize, whether or not checkSizeConstraints reported success.

- When dragging an editor between displays, Live will continue to call
  checkSizeConstraint and onSize with the editor’s old size in physical
  pixels. In some cases, JUCE's "scale factor check" timer callback
  fires, resizes the view to the correct size, and then Live
  asynchronously calls onSize again with the editor's old size in
  physical pixels, resulting in the editor being set to the wrong
  logical size.

This patch ensures that checkSizeConstraint always returns the current
size of a nonResizable editor. This means that the logical size of the
editor should not change when the result of checkSizeContraint is used
to resize the window.

Fixes an issue introduced in 72fa2d98e1
where zeromem might write past the end of the channel buffer.

The host is guaranteed to re-scan all parameter values after setting a
new state on the plugin, so there's no need to notify the host about
parameter changes that happen during the setState call.

This also avoids a problem where Bitwig would complain about invalid
parameter IDs in 'engine.log' when loading projects containing JUCE
VST3s. These log messages were produced because a call to setState was
made before Bitwig registered the plugin's parameters, and the setState
call in turn called performEdit with parameter IDs that were yet to be
registered.

In CoreGraphicsPixelData::createImage, image data was copied from a
BitmapData created from the Image passed into the function.

The BitmapData instance didn't keep track of the size of the buffer it
pointed to, so the buffer size was computed by multiplying the
BitmapData height by its line stride. However, if the BitmapData pointed
to a subsection of an image, the `data` pointer might be offset from
the allocated region, and `data + lineStride * height` would point past
the end of the allocated region. Trying to read/copy this range would
cause a heap buffer overflow at the end of the range.

This change adjusts BitmapData so that it keeps track of the size of the
allocated region. Taking a subsection of an image should subtract the
data pointer offset from the size of the allocated region.

This autorelease was accidentally removed in
2a199d5225

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.

Note that hosts using the AUv2 API (e.g. JUCE hosts) to host JUCE AUv3
plugins may not receive begin/end gesture events, depending on the OS
version, and potentially the host architecture. I suspect this is
because older versions of the OS-provided AUv2/AUv3 translation layer
don't handle these events.

In testing, an Intel host on Catalina did not receive begin/end events,
but an Arm host on Monterey did receive these events.

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.

Previously, with two instances of the MIDILogger AUv3 in series in
Logic, the timestamps received by the second plugin in the chain would
not match the timestamps of the events emitted by the first plugin.

This fixes a bug where selecting "Always on top" in the plugin editor
window in Cubase 11 on Windows 11 on a display with > 100% scale would
cause the editor to display with the wrong scale factor.

It seems that Cubase calls removed() then attached() on the plugin view,
destroying and recreating the editor wrapper component. The editor
opened with 100% scale, but requests from the host to set the "real"
scale factor were ignored because the JUCE wrapper thought that the
requested scale had already been applied.

Applying the cached scale factor directly after constructing the editor
keeps everything in a consistent state, and seems to resolve the issue.

This change allows mouse events (including enter and exit events) to
reach unfocused views on macOS. This matches the behaviour of unfocused
windows on Linux and Windows, where components paint in their "hovered"
states even when the application window is in the background.

As a byproduct of using tracking areas on macOS, we can remove the fake
mouse move generator.

Hosts such as REAPER normalise the program parameter value by dividing
the program value by the step count, rather than going via the
parameter's toNormalized function. To be compatible, we should use the
same scaling technique. At time of writing, the coversion process is
detailed under the heading "Conversion of normalized values" on this
page:

https://developer.steinberg.help/display/VST/Parameters+and+Automation