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.

When drawing a popup menu for a target component with a non-unity scale,
the contents of the component were being drawn with an unwanted vertical
offset.

When passing in valid data with zero size, replaceWith() will do nothing and leave the MemoryBlock in its previous state which may be unexpected. replaceAll() will reset the MemoryBlock and resize it to 0

The plugin should interpret the arguments as VstSpeakerArrangement**
instances. It should modify the pointed-to VstSpeakerArrangement* so
that it points to a long-lived VstSpeakerArrangement in the plugin.

Audition incorrectly increments the ref-count of the IPlugView* returned from IEditController::createView() and never fully releases it. This commit reverts e0306d25 for Audition to ensure that an editor is always returned, otherwise Audition displays a blank GUI.

This fixes a regression introduced by
6e9261ea66 which meant that components
were not given a chance to respond to shortcut keypresses if those same
keypresses were registered for a menu item. This resulted in behaviour
where shortcuts such as 'cmd+c' would not be passed to a focused
TextEditor if a different command with the same shortcut was registered
in the main menu.

With this change in place, we now check whether the menu item's shortcut
keys match the current event's pressed keys. If the keypresses match, we
can assume that the event was triggered by the keyboard, and dispatch
the keypresses to the ComponentPeer. If the keypresses do not match,
then the menu item was likely selected using space/return, or by
clicking, in which case the event is dispatched directly to the
ApplicationCommandManager.