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 change stops menus from displaying under notches/cutouts on mobile
platforms.

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.

Adds a new `drawPopupMenuBackgroundForOption` member function to
`PopupMenu::LookAndFeelMethods`. By default this will pass through
to `drawPopupMenuBackground`, but it can be overridden in cases
where the background appearance depends on the current `Options`.