This includes Carbon support

This restores the functionality of JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS.
Using this preprocessor flag may avoid Core Graphics rendering much larger regions than
necessary, but the small regions that are rendered will likely be rendered slower.
Whether using this flag improves or degrades the performance of your rendering overall
will be specific to each application.

Previously enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS was ineffective
from versions of macOS around 10.13, but enabling it didn't have any negative impact on
performance. Now enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS may result
in slower rendering.

This restores the functionality of JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS.
Using this preprocessor flag may avoid Core Graphics rendering much larger regions than
necessary, but the small regions that are rendered will likely be rendered slower.
Whether using this flag improves or degrades the performance of your rendering overall
will be specific to each application.

Previously enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS was ineffective
from versions of macOS around 10.13, but enabling it didn't have any negative impact on
performance. Now enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS may result
in slower rendering.

The helper function setComponentAsyncLayerBackedViewDisabled has been replaced
by a windowRequiresSynchronousCoreGraphicsRendering ComponentPeer style flag.

This partially reverts f43784dc: "macOS:  Propagate focus loss message when resigning key window status and only grab focus if window can become the key window"

eabcfbad26 incorrectly set the collection
behaviour NSWindowCollectionBehaviorFullScreenPrimary on all top-level
components, which would cause popup menus and callouts to appear in
their own space when launched from an app running in full-screen mode.

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.

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 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.

Ideally, we want to pass shortcut keys to the component to handle, and
only fall back to invoking a menu item if the component was unable to
handle the keyboard event, or if the action was triggered by
clicking/selecting an item in the menu itself. The old implementation
tried to work out whether the action was triggered by a shortcut by
checking the event's characters and modifiers. This method was
inaccurate, because some shortcuts (such as arrow keys) may add
unexpected numpad/function modifier flags.

We now try handling shortcut keys directly in the peer, and pass events
up to the superclass (which will forward them to the main menu) if the
event could not be handled.

This commit also adjusts some Objective-C method signatures to use the
correct string encoding for the BOOL type.

Some plugins (Izotope Relay, some older DPF plugins) use NSTrackingAreas
to handle mouse events, but unprocessed events seemingly get passed up
to outer views. Processing these events was causing unexpected
behaviour. For example, if the cursor entered a plugin view while
dragging a JUCE window border, a mouseEnter event was be generated,
interrupting the drag.

We now check whether mouse events were generated by an NSTrackingArea
which does not belong to the JUCE view, and ignore the event in this
case.

This commit also removes the subview from its superview's subview array before re-ordering as the macOS docs don't make any guarantees about what happens when adding a subview that is already contained in the array.