When FileChooser instances were created, launched, and hidden all inside
the same event callback on macOS 12.0.1, the chooser dialog sometimes
remained open. This could cause problems including crashes, as closing
the dialog would attempt to call a completion handler block referencing
an already-deleted FileChooser::Native instance.

Opening the chooser panel later on the message thread seems to resolve
the issue.

It seems like shared_from_this may not be enabled when a unique_ptr is
assigned to a shared_ptr (although it *should* be enabled when
constructing a new shared_ptr from a unique_ptr). Functions that return
objects that may need to use shared_from_this now return shared_ptr,
just to be safe.

Additionally, in some cases, shared_from_this was being called from
Thread::run after the last reference to the shared object had been
released. We now call shared_from_this during 'open', which will always
run on the message thread while at least once reference to the shared
object is alive.

Some hosts (such as Reaper) weren't creating an instance of exactly
NSOpenPanel or NSSavePanel, which meant that the call to
`getSelectedPaths` was always returning an empty array.

Now, rather than trying to cast the sender to an appropriate type, we
assume that the sender is always the same panel that we opened earlier,
so that we can just query the panel directly for its selection.

Previously, when a file dialog was launched synchronously, the 'dummy' modal
component was preventing user input events from reaching the preview component.

Now, we explicitly allow input events to reach the file preview component, if
it exists.

If the preview is not removed from the desktop, the FileChooser will try to reuse
the same ComponentPeer the next time the preview component is used.

Previously, when the FileChooser::Native instance entered the
modal state, it was preventing the inner FilePreviewComponent from
receiving events.