glsl ES: Fix magnitude of MaxVertexUniformVectors.

Previously, we set it equal to MaxVertexUniformComponents.  It should
be MaxVertexUniformComponents / 4.
glsl: Make gl_TexCoord compatibility-only

gl_TexCoord was deprecated in GLSL 1.30.  In GLSL 1.40 it was marked
as ARB_compatibility-only, and in GLSL 1.50 and above it was marked as
only appearing in the compatibility profile.  It has never appeared in
GLSL ES.

However, Mesa erroneously included it in all desktop versions of GLSL,
even versions 1.40 and 1.50 (which do not currently support the
compatibility profile).  This patch makes gl_TexCoord available in the
compatibility profile (and GLSL versions 1.30 and prior) only.
glsl: Rework builtin_variables.cpp to reduce code duplication.

Previously, we had a separate function for setting up the built-in
variables for each combination of shader stage and GLSL version
(e.g. generate_110_vs_variables to generate the built-in variables for
GLSL 1.10 vertex shaders).  The functions called each other in ad-hoc
ways, leading to unexpected inconsistencies (for example,
generate_120_fs_variables was called for GLSL versions 1.20 and above,
but generate_130_fs_variables was called only for GLSL version 1.30).
In addition, it led to a lot of code duplication, since many varyings
had to be duplicated in both the FS and VS code paths.  With the
advent of geometry shaders (and later, tessellation control and
tessellation evaluation shaders), this code duplication was going to
get a lot worse.

So this patch reworks things so that instead of having a separate
function for each shader type and GLSL version, we have a function for
constants, one for uniforms, one for varyings, and one for the special
variables that are specific to each shader type.

In addition, we use a class, builtin_variable_generator, to keep track
of the instruction exec_list, the GLSL parse state, commonly-used
types, and a few other variables, so that we don't have to pass them
around as function arguments.  This makes the code a lot more compact.

Where it was feasible to do so without introducing compilation errors,
I've also gone ahead and introduced the variables needed for
{ARB,EXT}_geometry_shader4 style geometry shaders.  This patch takes
care of everything except the GS variable gl_VerticesIn, the FS
variable gl_PrimitiveID, and GLSL 1.50 style geometry shader inputs
(using the gl_in interface block).  Those remaining features will be
added later.

I've also made a slight nomenclature change: previously we used the
word "deprecated" to refer to variables which are marked in GLSL 1.40
as requiring the ARB_compatibility extension, and are marked in GLSL
1.50 onward as requiring the compatibilty profile.  This was
misleading, since not all deprecated variables require the
compatibility profile (for example gl_FragData and gl_FragColor, which
have been deprecated since GLSL 1.30, but do not require the
compatibility profile until GLSL 4.20).  We now consistently use the
word "compatibility" to refer to these variables.

This patch doesn't introduce any functional changes (since geometry
shaders haven't been enabled yet).
i965: Add an assertion to brwProgramStringNotify.

driver->ProgramStringNotify is only called for ARB programs, fixed
function vertex programs, and ir_to_mesa (which isn't used by the i965
back-end).  Therefore, even after geometry shaders are added,
brwProgramStringNotify should only ever be called with a target of
GL_VERTEX_PROGRAM_ARB or GL_FRAGMENT_PROGRAM_ARB.

This patch adds an assertion to clarify that.
glsl/linker: Make update_array_sizes apply to just uniforms.

Commit 586b4b5 (glsl: Also update implicit sizes of varyings at link
time) extended update_array_sizes() to apply to both uniforms and
shader ins/outs.  However, doing creates problems for geometry
shaders, because update_array_sizes() assumes that variables with
matching names in different parts of the pipeline should have the same
sizes.  With the addition of geometry shaders, this is no longer true
(e.g. both vertex and geometry shaders have a gl_ClipDistance output
variable, but there's no reason these variables should have the same
sizes).

The original reason for commit 586b4b5 (avoid problems with
gl_TexCoord being 0 length) has since been addressed by commit 6f53921
(linker: Ensure that unsized arrays have a size after linking).  So go
ahead and switch update_array_sizes() back to only acting on uniforms.
!UPSTREAM: glsl: Enable various extensions for geometry shaders.

Note: In principle there's no reason geometry shaders couldn't support
OES_texture_3D and OES_EGL_image_external, but it seems silly to
enable them, since these are GLSL ES extensions, and geometry shaders
aren't allowed in GLSL ES.

TODO:
- Better commit message
- Better testing
main: Fix geometry shader error messages (missing right paren)
!UPSTREAM ===== BEGIN rebase of Plombo's GS patches =====
draw/gs: fix allocation of buffer for GS output vertices

Before, it accounted for the size of the vertices but not the other fields
in the vertex_header struct, which caused memory corruption.
mesa: add EXT_geometry_shader4 and ARB_geometry_shader4 to extension list
mesa: account for geometry shader texture fetches in update_texture_state
glcpp: define extension macros for EXT/ARB_geometry_shader4
glsl: add builtins for EXT/ARB_geometry_shader4

v2 (Paul Berry <stereotype441@gmail.com>): Account for rework of
builtin_variables.cpp.
glsl: add ir_emitvertex and ir_endprim instruction types

These correspond to the EmitVertex and EndPrimitive functions in GLSL.

v2 (Paul Berry <stereotype441@gmail.com>): Add stub implementations of
new pure visitor functions to i965's vec4_visitor and fs_visitor
classes.
glsl: lower gl_ClipDistanceIn to gl_ClipDistanceInMESA in lower_clip_distance

This corresponds to the lowering of gl_ClipDistance to gl_ClipDistanceMESA.
It converts the 2D array gl_ClipDistanceIn from EXT/ARB_geometry_shader4 to
a 1D array of vec4s, gl_ClipDistanceInMESA.

v2 (Paul Berry <stereotype441@gmail.com>): Fix indexing order for
gl_ClipDistanceIn lowering.  Properly lower bulk assignment of
gl_ClipDistanceIn[i].
glsl: support compilation of geometry shaders via EXT/ARB_geometry_shader4

This commit adds all of the parsing and semantics for EXT/ARB_geometry_shader4,
including support for 2D arrays as inputs.

v2 (Paul Berry <stereotype441@gmail.com>): Adjust i965's
brw_link_shader() to pass the new is_geometry_shader argument to
do_set_program_inouts.  Add a few missing calls to
get_pipeline_stage().  Fix some signed/unsigned comparison warnings.
Fix handling of NULL consumer in assign_varying_locations().

v3 (Bryan Cain <bryancain3@gmail.com>): fix indexing order of 2D
arrays.  Also, allow interpolation qualifiers in geometry shaders.

v4 (Paul Berry <stereotype441@gmail.com>): Eliminate
get_pipeline_stage()--it is no longer needed thanks to 030ca23 (mesa:
renumber shader indices according to their placement in pipeline).
mesa: Refactor copying of linked program data.

This patch creates a single function to copy the the UsesClipDistance
flag from gl_shader_program.Vert to gl_vertex_program.  Previously
this logic was duplicated in the i965-specific function
brw_link_shader() and the core mesa function _mesa_ir_link_shader().

This logic will have to be expanded to support geometry shaders, and I
don't want to have to update it in two separate places.
mesa: Copy linked program data for GS.

The documentation for gl_shader_program.Geom and gl_geometry_program
says that the former is copied to the latter at link time, but this
wasn't happening.  This patch causes _mesa_ir_link_shader() to perform
the copy, and updates comment accordingly.
glsl: Require geometry shader inputs to be arrays.
glsl/linker: Properly error check VS-GS linkage.

From the ARB_geometry_shader4 specification:

    A geometry shader may also read from an input varying variable declared
    with the "varying in" qualifiers. The value read will be the same value as
    written by the vertex shader for that varying variable. Since a geometry
    shader operates on primitives, each input varying variable needs to be
    declared as an array. Each element of such an array corresponds to a
    vertex of the primitive being processed. If the varying variable is
    declared as a scalar or matrix in the vertex shader, it will be a
    one-dimensional array in the geometry shader.

Therefore, a user-defined geometry shader input will always be an
array, and the *element type* of that array should match the type of
the corresponding vertex shader output.