Previously, getScreenPosition would return a result in the component's
coordinate space if it was called on a component that was not directly
or indirectly on the desktop. This behaviour is surprising and difficult
to program around. This change should ensure that the result is always
in the screen's coordinate space.

In cases where a VST3 plugin set a non-zero latency in its
prepareToPlay, and then set its latency to 0 later on, the host was not
notified about the latency change.

In older versions of the VST3SDK, hostContext is a raw pointer,
in newer versions it's a smart pointer. If we do manual
refcounting with the smart pointer, we may cause leaks.

The old design had us checking isActive inside our audio callbacks, and
also modifying isActive from prepareToPlay(), and releaseResources(). To
avoid race conditions, and to ensure that isActive actually reflects the
activation state of our plugin, we need to lock in these places. If we
don't lock, there's a chance that other threads will observe isActive to
be true while the plugin is not actually active (for example).

If you're not convinced, imagine this scenario:
- The message thread calls prepareToPlay. The plugin is activated.
- The audio thread starts calling processBlock, and gets as far as the
  isActive check. The plugin appears active, so we continue into
  processBlock.
- At the same time, the message thread calls releaseResources(). The
  processBlock call is still in progress, but the message thread is
  simultaneously making calls to setProcessing() and setActive(), which
  is a race.

Normally, it'd be up to the host of the AudioProcessor to ensure that
prepareToPlay() isn't called at the same time as processBlock().
However, VST3 plugins can request a restart at any time from the UI
thread, requiring us to call prepareToPlay() even while processBlock()
is running.

Previously, IEditController parameter indices were being used to index
into the AudioProcessor parameter array, but these parameter indices are
not guaranteed to point to the same parameter (parameter groups may
cause reordering on JUCE's side). Now, we use the IEditController
indices universally.

Previously, the following plugins were causing issues when hosting their
editors:

- Softube plugins. I used Saturation Knob for testing, which crashed when
  deleting the temporary parent view.
- KORG Gadget series, which displayed a black screen after the temporary parent
  view was deleted.
- FabFilter Pro-C, which displayed at the wrong scale when opened on a
  retina display.

Old PluginDescriptions may only have the `deprecatedUid` field set, with
the `uniqueId` field set to 0. In this case, the uniqueId should be
ignored, and the deprecatedUid used instead.

This change ensures that popup menus will be dismissed when hosted
plugin windows are moved, even when these plugin views are themselves
hosted inside JUCE views, like those used in the AudioPluginHost.