AUs are more likely to have 16 channels on a bus now that the 9.1.6
Atmos layout is available.

On Windows, broughtToFront may be called during the destructor of
VSTPluginHost, adding the window back into activeVSTWindows, leading to
a heap-use-after-free in vstHookWndProc.

This change means that broughtToFront will only reorder
activeVSTWindows; it will never add a window that's not already in the
list.

This allows paths that are prefixed with environment variables to behave
as expected. This is useful when scanning the default LV2 locations in
the AudioPluginHost on Windows.

Some hosts (e.g. REAPER) will attempt to instantiate plug-ins with 64
active channels, and JUCE can't represent this layout. In this case,
failing to convert between VST3/JUCE layouts is not a logical error, so
asserting is not appropriate.

Previously, all parameter changes were routed first into
cachedParamValues. Then, on each audio callback, an update would be sent
to the editor via the parameterDispatcher for each changed value in
cachedParamValues.

Now, parameter changes are immediately added to the parameterDispatcher,
without needing to wait for an audio callback.

In Windows DLL builds we inject operator new/delete definitions into
classes with a leak detector. This requires that all inheritance from
such classes must be public, and classes inheriting from multiple such
classes must disambiguate between the base's operators.

The VST3 spec disallows adding/removing parameters at runtime.
As far as I can tell, there's no way for a plugin to signal to the host
that the unitIds of one or more parameters have changed, so I suspect
these are not allowed to change at runtime either.

Given this, I can't think of a good reason for refreshParameterList to
have any effect for VST3 plug-ins.

Co-authored-by: Dan Raviv <dan@soundradix.com>