Instead of having Meson determine the invocator through the shebang
line we explicitly pass the script file to the Python interpreter.

This will allow us to either use Python3 or Python2, or whatever
Python.exe is available on Windows.

For the Visual Studio C compiler we need to annotate our public symbols
with `__declspec(dllimport)` to ensure they are visible when dynamically
linking to Epoxy's DLL.

This is needed because under Windows we use a dispatch table, instead of
wrapper functions, thus the symbol visibility rules change. Compiling
with MingW will automatically add `__declspec(dllimport)` for us.

Thanks to Nirbheek Chauhan for the help in debugging the issue.

Fixes #104

meson: Don't call find_program objects with python

Similar to `epoxy_has_glx()`, but for the EGL windowing system API.

Libraries and applications that depend on Epoxy currently have no way to
safely degrade functionality if they are used on a platform without GLX
support; the only way to achieve that is to perform a symbol check
themselves, by essentially copying what Epoxy already does.

By exposing `epoxy_has_glx()`, those libraries and applications now have
the chance of querying Epoxy itself and gracefully handle failure.

Now that we have Doxygen generating it, we should fill out the API
reference for Epoxy.

Older versions of the Microsoft Visual C compiler do not support C99 and
do not have stdbool.h.

Additionally, Epoxy is pretty much C89 compliant, and stdbool.h is part
of C99.

We can add a simple fallback for MSVC, in case we end up getting built
with it.

On UNIX-like OSes, the OS will read the shebang and use the correct
interpreter, and on Windows, Meson will read the shebang and use the
correct interpreter.

Adding it manually will cause python to try to interpret python