With this change, libepoxy can be consumed as a subproject without
making any changes to the build files of a project. All you need to do
is provide a wrap file with a `[provide]` section:

https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section

This is also necessary because otherwise projects need to hard-code
the subproject name, which might be `libepoxy` when using `wrap-git` or
`libepoxy-1.5.10` when using `wrap-file` (to build from a release
tarball). This can cause conflicts between different subprojects that
consume libepoxy differently.

Other projects like glib, cairo, pango, etc already do this.

Libepoxy currently depends on all headers living under the same prefix.
This is not necessarily true: X11 headers can live in a separate prefix,
for instance under /opt/X11. This is also the case when cross-compiling to
a platform that sets up the build environment in non-standard ways.

We could add `x11_dep` and `egl_dep` to the libepoxy target dependencies,
but that could potentially add spurious linker flags and cause libepoxy to
depend on libraries it will dlopen() during normal operations.

To avoid that case, we use a partial_dep() object from Meson, and we limit
the dependency to compiler flags and inclusion paths.

GTK currently fails to detect if epoxy has been built with EGL on
Windows when epoxy is a subproject. To fix that it needs to get that
information from the dependency variables.

This requires Meson >=0.54.0 for setting variables in
declare_dependency().

Instead of tweaking the linker flags ourselves. This allows Meson to do
the right thing, and pass the arguments only where needed.

Python 2 is going to reach EOL in January 2020, and most platforms have
already moved to Python 3.

Meson complains even in the face of a version check.

Epoxy updates the function pointers in order to avoid calling the
resolver multiple times, but with -Bsymbolic we're going to update the
copy inside libepoxy, instead of the relocated copy in the code using
libepoxy. This leads to libepoxy constantly querying the function
resolver code instead of just once.

We still want to avoid intra-library relocations for our functions,
but we need to live with them for our global function pointers.

See issue #171

We're missing a dash.

Meson 0.46 introduced a function to check for linker flags passed to the
compiler; since the version is really brand new, I don't want to bump
the dependency on Meson just yet, so we're going to conditionally use
get_supported_link_arguments() only if we're building with Meson 0.46 or
later.

Even though meson will find the dependency gl on macOS, this does not mean that
there is a pkg-config file for it, as meson does not use pkg-config to
establish its presence. It should therefore not be added to
the libepoxy pkg-config file as a (private) requirement.