GBM alternate backend discovery and loading

From my reading, the GBM core code was intended to support, or perhaps at some point in the past did support loading backends other than the built-in DRI one. This series extends the current code to enable loading of alternate backends in general, and as a straw-man proposal, specifically uses the DRM driver name of the FD passed to gbm_create_device() to construct a library name of a potential alternate backend. Other schemes could be implemented on top of the basic functionality added here, but this simple one seemed sufficient.

Issues addressed in the series:

• The ability to dynamically load backends from DSOs.
• Thread-safe tracking and refcounting of dynamically-loaded backends.
• Versioning of the GBM driver ABI to enable backwards and forwards binary compatibility between the GBM loader and backends.
• Discovery of alternate/external backend DSOs.

Here's a rundown of the backend discovery logic implemented in the series:

• If the GBM_BACKEND env var is set, attempt to load the backend library it names and create a device from it if found.
• If that fails or the env var is not set, call drmGetVersion() on the fd, and if that succeeds, attempt to load libgbm_.so.0 and create a device from it if found.
• If that fails, try the built-in DRI backend.