Previously, code such as the following (where MyGLComponent is rendering
using an OpenGLContext) could result in GL errors, as the destruction of
the inner context unbound the array buffer and element array buffer
after use, instead of setting them to the previous values set up by the
outer context.

Additionally, a VAO was only set up in the OpenGLContext, so rendering
into a GL-backed LowLevel graphics context could fail if no VAO was
bound.

    void MyGLComponent::paint (juce::Graphics& g)
    {
        juce::Image image { juce::Image::PixelFormat::ARGB, width, height, false, juce::OpenGLImageType() };

        {
            juce::Graphics innerContext { image };
            // draw into innerContext
        }

        g.drawImage (image, juce::Rectangle<float> { width, height });
    }

On these platforms, calling flushBuffer from multiple threads
simultaneously will lead to deadlocks.

This change fixes an issue where opening multiple OpenGLContexts on
certain versions of macOS (observed on 10.13) could cause a deadlock.

The issue can be reproduced by:
- Attaching an OpenGL context to the AudioPluginDemo editor
- Opening multiple copies of the editor simultaneously in a plugin host.
  I tested with Live 10.

I also observed the issue in a standalone app that opened new windows
containing OpenGLContexts on a timer.

On Windows, the OpenGL context window sometimes receives a repaint
request after moving between screens with different scale factors.
If the screen has changed size/scale since the last paint operation,
failing to invalidate the painted area may cause the screen contents
to be drawn at the wrong scale until paint is next called.

- 4.1 and 4.3 contexts can now be requested
- The requested context version is no longer ignored on Linux
- Debugging contexts are now enabled in Debug builds with GL 4.3
- Fixes a bug where glEnable(GL_TEXTURE_2D) was called in core profiles

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

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.

Previously, Xcode's main thread checker would complain when selecting
the "OpenGL Renderer" in the DemoRunner on macOS.