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.

The OpenGL renderer uses ColourGradient::createLookupTable to generate
gradient textures. However, the tweening method used was different to
the tweening used by CoreGraphics gradients, and by the software
renderer.

Gradient tweening is now computed using non-premultiplied colours, to
ensure consistency between gradients rendered using OpenGL, and with
other renderers.

The significant change here is that the XSaveContext call in the OpenGL
NativeContext now has a matching XDeleteContext call. This breaks the
connection between the X window and the ComponentPeer, so that we avoid
dereferencing a dangling ComponentPeer pointer if the window receives
events after the peer is destroyed.

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 current minimum-supported Xcode (10.1) includes the macOS 10.14.1
SDK, so APIs from macOS 10.12 will always be available.