Shaves another 14k off the binary:

1114236	  56800	    160	1171196	 11defc	providernames.so
1099948	  56800	    160	1156908	 11a72c	enumstrings.so

Fixes #202

Saves 7k of text from the binary.  You can already tell what kind of
extension it is from the prefix on the extension name anyway.

1121212	  56800	    160	1178172	 11fa3c	master.so
1114236	  56800	    160	1171196	 11defc	providernames.so

This will distinguish them from the exposed extension presence

Meson complains even in the face of a version check.

Looking for a symbol named "libGLESv2.so.2" is probably not going to
work very well.

When building on macOS we don't have access to EGL, and GLX support is
conditional.

We should ensure we're using the appropriate paths depending on the
platform, and protect our use of macros to avoid undefined symbols.

Closes: #176

EGL is not available on macOS, except through Objective C.

Our caller may load (eg) epoxy_glAlphaFunc, which is a function pointer,
and then call through that value multiple times. Until the caller
re-examines the value of that function pointer, which is a copy
relocation in the executable, repeated calls mean repeated work
resolving the GL function.

We can't make the caller reinspect the variable, but the resolver
function can avoid doing redundant work.

Fixes: anholt/libepoxy#171
Signed-off-by: Adam Jackson <ajax@redhat.com>

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