The Apple threading documentation [^1] says the following:

> The second argument to pthread_setschedparam is the desired policy,
  which can currently be one of SCHED_FIFO (first in, first out),
  SCHED_RR (round-robin), or SCHED_OTHER. The SCHED_OTHER policy is
  generally used for extra policies that are specific to a given
  operating system, and should thus be avoided when writing portable
  code.

This appears to differ from the policy semantics on Linux and BSD, where
FIFO and RR are both explicitly real-time policies.

Therefore, on Linux/BSD we only enable the RR policy if the requested
priority is 8 or higher. Meanwhile, on macOS, we map all thread
priorities (0 - 10) onto the RR policy with an appropriate priority.

[^1]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html

Previously, we were using the window's top-left position to determine
the scale to use for the OpenGLContext. However, on macOS the
backingScaleFactor of the window is not strictly related to the top-left
corner of the window, so the OpenGL view's scale could end up differing
from the backing scale factor when slowly moving a window between
displays with different backing scale factors.

On macOS, we now use the backing scale factor of the window's screen (as
maintained by AppKit), rather than trying to work out the correct
display and scale ourselves.

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.

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.