This allows the LookAndFeel of submenus to query the target component
used for the top-level menu. getTargetComponent() isn't suitable for
this because the target component is set to null for submenus, and this
behaviour can't be changed without potentially breaking code that relies
on the current behaviour.

In cases where no JUCE component had keyboard focus, clicking a menu
item would cause the menu to be dismissed instead of triggering the
item's action.

- Created a new detail namespace
- Moved shared module implementation details into the detail namespace
- Split dependencies so source files only rely on details in the detail namespace
- Removed all code from the juce_gui_basics.cpp file

Without this VoiceOver will iterate over menu items left to right first,
and iteration order will be affected by whether the PopupMenu gets
broken up into multiple columns due to not enough screen space.

Previously, for the following snippet, the menu's LnF was incorrectly
being forced to the default LnF. The correct behaviour is to display the
menu using LnF v4. The menu doesn't have an explicit LnF set, so it
should use the LnF of its parent component.

    LookAndFeel::setDefaultLookAndFeel (&lookAndFeel_V1);
    setLookAndFeel (&lookAndFeel_V4);
    PopupMenu().showMenuAsync (PopupMenu::Options{}.withParentComponent (this));

Prior to this commit it was possible to get the menu bar deactivated
by moving the mouse to an adjacent menu item and then back again. If
the movement was quick enough the corresponding PopupMenu would be
dismissed and created again before the dismissal's async command
handler would run. The command handler would see that the dismissed
menu's index and the currently activated index are equal and
deactivate the menu bar.

These crashes could be seen in the DemoRunner when selecting items in
nested PopupMenu windows.

These crashes could be seen in the DemoRunner when selecting items in
nested PopupMenu windows.

Also updates the drop shadower so that the DPI-awareness of the shadows
matches the DPI-awareness of the shadowed component.

Previously it was possible to inadvertently activate a menu item by
clicking on a submenu item that was drawn on top of the parent menu.

The root cause was that hide() initiates an asynchronous mechanism
through exitModalState() that eventually destroys the MenuWindow, but
the MouseSourceState timer callbacks and event handlers sometimes still
had a chance to do a state update. Since the submenus have just been
destroyed the update could mistakenly conclude to activate one of the
items of the now lone parent.

The 'wrapper' accessibility handler is now ignored if a menu item has a
custom component, and has no submenu, and cannot be triggered
automatically. This avoids the case where a custom menu item may end up
with a wrapper accessibility handler that has no useful actions.

This patch also adds a 'label' argument to the addCustomItem functions,
which allows text for the screen reader to be supplied in the case where
a custom component is in use, but the menu item has accessibility
actions.

This change is designed to fix issues with views stealing focus and
being brought to the front when popup menus are dismissed.

To test this behaviour:
- Open two instances "a" and "b" of a plugin editor containing a
  ComboBox
- Click the ComboBox in editor "a", opening its PopupMenu
- Drag the titlebar of editor "b" to move it
- The PopupMenu should be dismissed, but editor "a" should *not* steal
  keyboard focus or be brought to the front

This commit removes the various compiler-specific JUCE_DEPRECATED macros and replaces them with C++14's deprecated attribute. It also removes the JUCE_CATCH_DEPRECATED_CODE_MISUSE flag as we can rely on the override specifier catching usage of these old virtual methods, and tidies up the DOXYGEN preprocessor checks as they were inconsistent across the codebase.

This change stops menus from displaying under notches/cutouts on mobile
platforms.

See BREAKING-CHANGES.txt for more details.

When bridging 32-bit/64-bit plugins on Windows, the plugin is hosted in
an auxilliary process, and the plugin's editor is embedded into an HWND
owned by a different process (the plugin host).

Previously, the `isForegroundProcess` check would fail for bridged
plugins, because the foreground window may belong to the DAW, rather
than to the auxilliary hosting process.

This patch adds an additional check, to find whether the same process
owns both the foreground window, and the window which embeds the
PopupMenu's target component. In this case, we avoid immediately
dismissing the PopupMenu.

This behaviour was already present on windows, so this patch updates
Linux and macOS window-handling to match.