This includes Carbon support

This is intended to fix two issues:
- In REAPER, setting automation recording to 'Latch', recording some
  automation, saving and reloading the project, then starting playback causes
  automation data to be overwritten. This appears to be because REAPER
  interprets parameter change messages sent during state restoration as
  originating from the user.
- In Ableton Live, automation lanes are sometimes disabled when loading
  projects. This also seems to be because the setStateInformation call
  may send parameter change messages back to the host.

According to the docs for kAudioUnitProperty_ClassInfo, the host is
required to notify all parameter listeners that the parameter values may
have changed, implying that the plugin need not send its own parameter
change notifications during state restoration.

Some AUv3 presets crash when querying the set of presets in Loopy Pro.
The issue seems to be because `addPresets` may end up being called
concurrently with the host's queries.

Some AUv3 presets crash when querying the set of presets in Loopy Pro.
The issue seems to be because `addPresets` may end up being called
concurrently with the host's queries.

This is an implementation detail for the build system of the plugin.
Users of the plugin should not know or care that this extension is
available.

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.