GLX: Fix GLXFBConfig mapping with multiple displays

Created by: kbrenneman

Apparently, there are some applications that depend on being able to look up a GLXFBConfig handle from one display connection, and then use that config on another display. Libglvnd can't currently deal with that, because it expects those handles to be unique and never used outside whatever display they came from.

These changes are to make libglvnd more flexible (or at least, more robust) to that sort of behavior. Most of this is simply to change the bookkeeping and the ABI so that libGLX keeps a mapping from GLX objects (drawables, contexts, configs) directly to vendors, without keeping track of the display or screen for any of them.

For dispatching to work, GLXContext and GLXFBConfig handles must be unique between vendor libraries. That is, two vendor libraries must never produce the same GLXContext or GLXFBConfig handle.

A single vendor library may, however, produce the same GLXFBConfig handle for different displays, possibly to different X servers. For instance, a vendor might use keep track of configs internally by their XID, so it could just have a mapping between XID values and GLXFBConfig handles. The same GLXFBConfig handle might then be used with different displays, and possibly different screens. As long as the GLXFBConfig handles are unique to a vendor, though, then libGLX can just dispatch everything to the correct vendor and not care about anything else.

Without keeping track of a screen number for GLXFBConfigs, we also can't record the screen for a GLXContext, since glXCreateNewContext takes a GLXFBConfig instead of a screen. Same thing with GLXDrawables, where without the x11glvnd extension, we can't find a screen number even now. In both cases, though, we still don't really need a screen, we just need a vendor, so that's what libGLX should keep track of.

That just leaves the issue of making sure that GLXContext and GLXFBConfig handles are unique between vendors. To do that, libGLX now specifies that the handles must be a real memory address. It doesn't matter what address it is, as long as it's something unique to the vendor library.