[Piglit] Cleaning up Piglit's crazy build system and GLES1 dispatch

[Chad Versace]

I'm working to clean up Piglit's crazy build system, which builds each
target multiple times, once for each supported API.

You can track my progress here:
    git://people.freedesktop.org/~chadversary/piglit refs/heads/unify-build
    http://cgit.freedesktop.org/~chadversary/piglit/log/?h=unify-build

When I'm done, the result should be:

    - Piglit will build each target (library and test executable) at most
      *once*. If a test executable needs to support multiple APIs, then
      the executable will determine which API to use at *runtime* rather
      than buildtime.

      For example, Piglit will no longer build libpiglitutil_gl,
      libpiglitutil_gles1, libpiglitutil_gles2, and libpiglitutil_gles3.
      Instead, all three will be folded into the generic libpiglitutil.
      The same will happen for the multiple flavors of shader_runner.

    - All per-API CMake files will be removed. That is,
            tests/util/CMakeLists.txt
            tests/util/CMakeLists.gl.txt
            tests/util/CMakeLists.gles1.txt
            tests/util/CMakeLists.gles2.txt
            ...
      will be replaced with a single
            tests/util/CMakeLists.txt

My motivation is that I want to generalize many desktop GL tests (shader
runner as well as C tests) to run also under a GLES context. And I want
to accomplish that without forking test files or building all of Piglit
multiple times.

The first step in unifying the build system is to extend piglit-dispatch
to support GLES1. I'm working on that now.

As I get closer to approaching to the final goal (generalizing the GL
tests to run under a GLES context), I'll start a discussion on the list
about how to best design the GLES-ification of Piglit.

-Chad