Fixes a bug introduced in 7d1918b385c600e1910dd5b744b583a42a26d8a1,
where Ozone 9's editor failed to open correctly in the AudioPluginHost.

The issue was caused by DropShadower using the ComponentListener interface
to listen to its target Component's changes and creating shadow Components
only if the target was visible during the event callbacks. However it was
possible that during the events the target was not yet visible because one
of its parents was not visible. When the parent became visible it would not
trigger a callback for the observed child component.

The fix attaches a ComponentListener recursively to all parents starting
from the target and responds to each componentVisibilityChanged() event.

Clang versions 5 to 8 inclusive seem to struggle to compile JUCE when
JUCE_BEGIN_NO_SANITIZE is used. This is unexpected, as simpler programs
using the same macro definitions compile correctly on clang 5.

Native Instrument VST3s (I tested Kontakt and Supercharger) crash when
the bundleEntry function is called from a background thread on macOS.
This change disables scanning for VST3 plugins on a background thread
using the PluginListComponent, to allow loading these plugins in the
AudioPluginHost.

I can't find any "official" word on whether the bundleEntry and
bundleExit functions should be guaranteed to be made from the main
thread. However, the VST3PluginTestHost app seems to call these
functions exclusively from the main thread.

This fixes an issue with NI Raum and Choral where the editors would open
in a new window, rather than in the same window as the VST
AudioProcessorEditor.

Adds a mechanism to notify the host that the plugin state needs saving,
using updateHostDisplay.

Also allows JUCE hosts to detect when a plugin needs its state saving
via the AudioProcessorListener.

On macOS 10.15, stdatomic.h (included by the VST3 SDK) defines a macro
named atomic_thread_fence when building in C++20 mode. This macro was
trampling over a call to std::atomic_thread_fence from the C++ atomic
header, made in juce_Atomic.h.

No JUCE implementation files use the C11 atomic functions, so I think
it's safe to just undef the problematic symbol after including all the
VST3 implementation files.