build: Require libepoxy

If we want to use OpenGL in GDK then we have two choices; either:

  - find the GL headers on each platform
  - do extension discovery
  - implement all the crazy dlopen()/dlsym() dispatch tables

*or* use libepoxy, which shields us from all this madness and provides a
decent layer for GL clients to use, without creating its own namespace.

Epoxy is also used by other projects, like Xorg and piglit, and it's
portable to all the platforms GDK cares about.

https://bugzilla.gnome.org/show_bug.cgi?id=119189
Add internal gdk_cairo_region_from_clip helper

This extract the current cairo clip region if possible and
returns it as a cairo_region_T. It will be needed by later code.
Change the way the update area is tracked during paint

First of all we track the current update area during an
update in window->active_update_area. This will be used later
in end_paint to know the damaged area.

Secondly we keep track of old update areas for the last 2
frames. This will later allow us to reuse old framebuffer
contents in double or tripple buffer setups, only painting
what has changed since then.
Add gdk_window_mark_paint_from_clip and call from widget drawing

This is a new function that gets called every time we're drawing
some area in the Gtk paint machinery. It is a no-op right now, but
it will be required later to keep track of what areas which
we previously rendered with GL was overwritten with cairo contents.
gdk: Add support for OpenGL

This adds the new type GdkGLContext that wraps an OpenGL context for a
particular native window. It also adds support for the gdk paint
machinery to use OpenGL to draw everything. As soon as anyone creates
a GL context for a native window we create a "paint context" for that
GdkWindow and switch to using GL for painting it.

This commit contains only an implementation for X11 (using GLX).

The way painting works is that all client gl contexts draw into
offscreen buffers rather than directly to the back buffer, and the
way something gets onto the window is by using gdk_cairo_draw_from_gl()
to draw part of that buffer onto the draw cairo context.

As a fallback (if we're doing redirected drawing or some effect like a
cairo_push_group()) we read back the gl buffer into memory and composite
using cairo. This means that GL rendering works in all cases, including
rendering to a PDF. However, this is not particularly fast.

In the *typical* case, where we're drawing directly to the window in
the regular paint loop we hit the fast path. The fast path uses opengl
to draw the buffer to the window back buffer, either by blitting or
texturing. Then we track the region that was drawn, and when the draw
ends we paint the normal cairo surface to the window (using
texture-from-pixmap in the X11 case, or texture from cairo image
otherwise) in the regions where there is no gl painted.

There are some complexities wrt layering of gl and cairo areas though:
* We track via gdk_window_mark_paint_from_clip() whenever gtk is
  painting over a region we previously rendered with opengl
  (flushed_region). This area (needs_blend_region) is blended
  rather than copied at the end of the frame.
* If we're drawing a gl texture with alpha we first copy the current
  cairo_surface inside the target region to the back buffer before
  we blend over it.

These two operations allow us full stacking of transparent gl and cairo
regions.
Add GDK_ALWAYS_USE_GL debug hack

If this is set we always use GL to render each window, even
if there are no GL widgets in the window.
wayland: Set GdkVisual::bits_per_rgb to 8

This was 0 before.
wayland: Add OpenGL support

This uses EGL to implement GdkGLContext for wayland.
Add GtkGLArea widget
Add tests/testglarea

This is a very simple test of GtkGLArea.
Add tests/gdkgears

A more complex test modeled on the traditional glxgears.
Add tests/testglblending

This test stacks GL and cairo rendering in various
orders to test the layer handling.
Add glarea demo to gtk3-demo
gl: Make all user GdkGLContexts not attached to any window

We make user facing gl contexts not attached to a surface if possible,
or attached to dummy surfaces. This means nothing can accidentally
read/write to the toplevel back buffer.
Fix warning
X11 GdkGLContext: Remove spurious XSync

This XSync doesn't seem to be necessary. Remove it until otherwise
proven.
gl: Make gdk_gl_context_make_current() return void

Its not really reasonable to handle failures to make_current, it
basically only happens if you pass invalid arguments to it, and
thats not something we trap on similar things on the X drawing side.

If GL is not supported that should be handled by the context creation
failing, and anything going wrong after that is essentially a critical
(or an async X error).
Correct Since tags
Correct copyright year
Trivial formatting fixes