Signed-off-by: falkTX <falktx@falktx.com>

Observed on Ubuntu Linux. Occasionally, the loop checking the
condition_variable in the plugin scanner would spin indefinitely.

The cause appears to be that handleMessageFromWorker could be
called immediately after sendMessageToWorker, but before locking the
mutex. If this happens, gotResponse will be false during every call to
condvar.wait_for, and the loop will never exit.

The rewritten version of the scanner always resets gotResult immediately
after the condvar is woken successfully, so a call to
handleMessageFromWorker or handleConnectionLost will always cause a
subsequent call to condvar.wait_for to exit successfully.

The Superprocess class has also been refactored and extracted to avoid
a circular dependency between Superprocess and CustomPluginScanner.

This includes Carbon support

This more closely matches the behaviour of CMake when adding rc files to
targets.

This also fixes an issue where the requested font style could be
incorrectly overwritten.

This more closely matches the behaviour of CMake when adding rc files to
targets.

This restores the functionality of JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS.
Using this preprocessor flag may avoid Core Graphics rendering much larger regions than
necessary, but the small regions that are rendered will likely be rendered slower.
Whether using this flag improves or degrades the performance of your rendering overall
will be specific to each application.

Previously enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS was ineffective
from versions of macOS around 10.13, but enabling it didn't have any negative impact on
performance. Now enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS may result
in slower rendering.