On Linux and other Unix variants we may not have access to GLX and EGL
at run time. Dependent libraries can only discover this by using dlsym()
on various symbols, because as soon as they attempt to call those
symbols through Epoxy, Epoxy will abort. This means that a bunch of code
needs to be copy-pasted between projects, with the high chance of
somebody getting it wrong.

Epoxy already has all the internals needed to detect whether GLX and EGL
are available, so exposing a simple API is a better alternative.

Fixes #73

Since X11 can be used on multiple platforms, or disabled in special
environments, we should provide a way to control whether or not Epoxy is
built with GLX support.

Fixes anholt/libepoxy#52
Fixes anholt/libepoxy#63
Closes anholt/libepoxy#80
Closes anholt/libepoxy#81

Since Epoxy can be built with different platform-specific API, having a
way for dependent projects to discover those capabilities without
necessarily crashing the minute they attempt to use them is a good
feature to have.

We strongly direct library and application developers to use pkg-config
in order to use Epoxy, so it makes sense to add variables to the
epoxy.pc file that can be easily extracted at configuration time.

After doing this for Meson in commit fc014fa1, let's do the same dance
for the Autotools build.

It's useful for people that like rummaging inside tarballs.

Both gz and bz2 tarballs are discouraged, in this day and age.

Currently, GLX support in libepoxy at build time is hard coded, but
various platforms have expressed their preference for having a
configure-time option for it.

For instance:

 - various embedded distributors do not ship with X11, but wish to use
   libraries that depend on libepoxy now that Wayland is available
 - distributors for macOS still wish to retain the ability to ship
   their software with X11 enabled

By default, we want epoxy to build with GLX enabled pretty much
everywhere it makes sense, since it's only a build-time option and it's
not a run-time dependency.