This change should mean that if JUCE is installed using one compiler
(e.g. clang) and then consumed in a build that uses a different compiler
(e.g. gcc), the helper targets will use the correct flags for both
compilers.
The CoreAudioKit (and on macOS, AudioUnit) frameworks are required to
host AudioUnit plugins. Hosts (especially those which don't use the
`juce_audio_utils` module) should use the new `PLUGINHOST_AU` parameter
to `juce_add_*` in order to add the correct preprocessor definition and
link the necessary frameworks.
On Linux, all these target kinds tried to create products with the same
name. Now we place each plugin target into a folder named after the
plugin kind, which allows each plugin kind to produce artefacts which
share names.
This change means that imported juce modules will be made available both
with and without a namespace prefix, e.g. `juce_core` and
`juce::juce_core` will both be created.
This change allows custom modules to specify dependencies without a
juce:: prefix, which allows the modules to be used with the Projucer, or
under CMake with JUCE in a subdirectory, or under CMake with JUCE
installed to the system.
Building AudioUnits with an older CMAKE_OSX_DEPLOYMENT_TARGET
(e.g. 10.9) but a newer sdk (e.g. 10.15) would result in link
failures. Linking against the AudioUnit framework supplies the
missing symbols.
AudioUnits built with the Projucer also link CoreAudioKit, so
we do that in CMake too for consistency.
Once JUCE has been built, you can use the following line to include
the targets from the build tree (replace `JUCE_BUILD_DIR` as
appropriate).
```
include("${JUCE_BUILD_DIR}/JUCEExportConfig.cmake")
```