Also updates the drop shadower so that the DPI-awareness of the shadows
matches the DPI-awareness of the shadowed component.

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 also fixes an issue where the requested font style could be
incorrectly overwritten.

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.

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.