Remove BindBufferRange out-of-range tests.

In the documentation for BindBufferRange, OpenGL specs from 3.0
through 4.1 contain this language:

    "The error INVALID_VALUE is generated if size is less than or
    equal to zero or if offset + size is greater than the value of
    BUFFER_SIZE."

This text was dropped from OpenGL 4.2, and it does not appear in the
GLES 3.0 spec.

Presumably the reason for the change is because come clients change
the size of the buffer after calling BindBufferRange.  Implementations
shouldn't generate an error at the time of the BindBufferRange call
just because the old size of the buffer was too small, when the buffer
is about to be resized.

Since this is a deliberate relaxation of error conditions in order to
allow clients to work, it seems sensible to allow implementations to
apply this change even if the GL version is less than 4.2.  This patch
eliminates the checks that would have required the error condition to
be flagged.

See associated Mesa patch:

    mesa: Don't check (offset + size <= bufObj->Size) in BindBufferRange.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

v2: Replace the removed checks with a comment noting that we're
explicitly not testing this language.
Test transform feedback of varying structs.

The test may be run either against GLSL ES 3.00 or against desktop
GLSL 1.50.  When desktop GLSL is tested, the test verifies proper
functioning both with and without the use of interface blocks.

This test is slightly meaner than what's currently necessary to verify
proper functionality in Mesa (in particular, it tests a variety of
different nestings of structs and arrays, even though no extra
implementation effort was necessary to make these tests pass).  I have
two reasons for wanting to write such a mean test:

- Varying structs in Mesa are currently implemented using a naive
  layout that packs structure and array contents in order with no gaps
  (in much the same way that structs are laid out in memory in C).
  It's likely that in the future we will need to replace this with a
  more sophisticated mechanism that "flattens" varying structs to
  their constituent fields.  Such an implementation will have
  important corner cases involving complex nesting of structs and
  arrays.

- During my implementation of this feature in Mesa (and my development
  of this test), I cross-checked against a competing implementation
  and found several bugs, particularly in cases involving complex
  nesting of structs and arrays.  It seemed worthwhile to write a test
  capable of detecting these bugs.
glslparsertest: Fix parsing of GL_SHADING_LANGUAGE_VERSION in GLES.

In desktop GL, glGetString(GL_SHADING_LANGUAGE_VERSION) returns a
string that begins with the supported version number.  But in GLES,
the version number is preceded by the text "OpenGL ES GLSL ES ".  This
was causing glslparsertest to fail to parse the implementation's
supported GLSL version, and that in turn caused parse_glsl_version()
function to access uninitialized memory.

This patch splits parse_glsl_version() into two functions:
parse_glsl_version_number(), which parses the bare version number, and
parse_glsl_version_string(), which expects the prefix "OpenGL ES GLSL
ES " when compiled for GLES testing.
glslparsertest: Don't require ES compatibility extensions when testing GLES.

glslparsertest should only check for the presence of
GL_ARB_ES{2,3}_compatibility when the test is running under desktop
GL.  GLES never exposes these extensions.
glslparsertest: Avoid uninitialized vars in parse_glsl_version_number.

Previously, if the user specified an ill-formed GLSL version number
(or the implementation supplied an ill-formed number in its response
to glGetString(GL_SHADING_LANGUAGE_VERSION)), glslparsertest would
access uninitialized variables, resulting in unpredictable (and often
confusing) behaviour.

With this patch, glslparser test accepts version numbers either of the
form "<int>" or "<int>.<int>".  Ill-formed version numbers lead to a
test failure.
WIP: GLES3: test that non-flat varying structs cannot contain ints.
shader_runner: Remove unimplemented geometry_program vestiges
WIP: shader_runner: Add support for testing geometry shaders.
WIP: test flat rules
WIP: fix test
WIP: shader_runner: choose GL version based on GLSL version more accurately
Modify tests for error checking on "flat" keyword to match updated specs.

All of the GLSL specs from GLSL 1.30 (and GLSL ES 3.00) onward contain
language requiring certain integer variables to be declared with the
"flat" keyword, but they differ in exactly *when* the rule is
enforced:

(a) GLSL 1.30 and 1.40 say that vertex shader outputs having integral
type must be declared as "flat".  There is no restriction on fragment
shader inputs.

(b) GLSL 1.50 through 4.30 say that fragment shader inputs having
integral type must be declared as "flat".  There is no restriction on
vertex shader outputs.

(c) GLSL ES 3.00 says that both vertex shader outputs and fragment
shader inputs having integral type must be declared as "flat".

Previously, Piglit simply checked for behaviour (a).  This patch makes
it check for behaviour (b) in desktop GL and behaviour (c) in GLES.

Rationale: once geometry shader support is included, (b) is the only
sensible choice, because it requires "flat" in just the situations
where it matters.  Since many implementations extend geometry shader
support back before GLSL 1.50 (via ARB_geometry_shader4), it seems
sensible to regard the difference between (a) and (b) as a bug fix
rather than a deliberate behavioural difference, and therefore test
for behaviour (b) even in GLSL 1.30.

Some discussion about this has already happened on the Mesa-dev list.
See:

http://lists.freedesktop.org/archives/mesa-dev/2013-February/034199.html