Co-authored-by: ValentynPavliuchenkoA <valentyn.pavliuchenko@avid.com>

This commit reverts c34f13a02d

In stripped plugin builds, the repostCurrentNSEvent function was still
public. There doesn't seem to be a good reason for this, as no host
should need to call the function.

It looks like the shared code component of a Projucer-generated plugin
project was briefly built as a framework that was shared by the
different plugin wrappers. In this scenario, the framework would need to
make repostCurrentNSEvent public so that the wrappers could locate the
function. However, now that the shared code target is built as a static
library, standard external linkage should be sufficient for the symbol
to be located from the wrapper's TUs.

Ideally, we want to pass shortcut keys to the component to handle, and
only fall back to invoking a menu item if the component was unable to
handle the keyboard event, or if the action was triggered by
clicking/selecting an item in the menu itself. The old implementation
tried to work out whether the action was triggered by a shortcut by
checking the event's characters and modifiers. This method was
inaccurate, because some shortcuts (such as arrow keys) may add
unexpected numpad/function modifier flags.

We now try handling shortcut keys directly in the peer, and pass events
up to the superclass (which will forward them to the main menu) if the
event could not be handled.

This commit also adjusts some Objective-C method signatures to use the
correct string encoding for the BOOL type.

This fixes warnings that are emitted when building with the `-analyze`
flag enabled.

IFileDialog::Show and CoUninitialize both seem to require the main
message loop to be active and running when they are called. If we block
the message thread while calling these functions, we may cause a
deadlock.

The destructor of the Win32NativeFileChooser was blocking the message
thread until the background thread exited, but the background thread was
unable to make progress while the message thread was blocked.

To work around this issue, we now pump the message thread in the
destructor of the Win32NativeFileChooser. If a dialog is currently
active, this should allow it to exit gracefully.

Note that we cannot use MessageManager::runDispatchLoopUntil here:
- MessageManager::runDispatchLoopUntil will not process any messages if
  the quit message has been received, which could lead to deadlocks if the
  FileChooser is destroyed after the quit message has been posted.
- This function isn't defined when JUCE_MODAL_LOOPS_PERMITTED is disabled.

Arranges declarations of objects with static storage duration to ensure
correct lifetimes.