glsl: Implement rules for geometry shader input sizes.

Section 4.3.8.1 (Input Layout Qualifiers) of the GLSL 1.50 spec
contains some tricky rules for how the sizes of geometry shader input
arrays are related to the input layout specification.  In essence,
those rules boil down to the following:

- If an input array declaration does not specify a size, and it
  follows an input layout declaration, it is sized according to the
  input layout.

- If an input layout declaration follows an input array declaration
  that didn't specify a size, the input array declaration is given a
  size at the time the input layout declaration appears.

- All input layout declarations and input array sizes must ultimately
  match.  Inconsistencies are reported as soon as they are detected,
  at compile time if the inconsistency is within one compilation unit,
  otherwise at link time.

- At least one compilation unit must contain an input layout
  declaration.

(Note: the geom_array_resize_visitor class was contributed by Bryan
Cain <bryancain3@gmail.com>.)
main: Warn that geometry shader support is experimental.

Geometry shader support in the Mesa front end is still fairly
preliminary.  Many features are untested, and the following things are
known not to work:

- The gl_in interface block
- The gl_ClipDistance input
- Transform feedback of geometry shader outputs
- Constants that are new in GLSL 1.50 (e.g. gl_MaxGeometryInputComponents)

This isn't a problem, since no back-end drivers currently enable
geometry shaders.  However, to make sure no one gets the wrong
impression, emit a nasty warning to let the user know that geometry
shader support isn't complete.
!UPSTREAM ===== END first series =====
!UPSTREAM: 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].

TODO: May need to rework for GLSL 1.50.
!UPSTREAM: glsl/linker: Fail if linking geometry shader with 0 GEOMETRY_VERTICES_OUT.

ARB_geometry_shader4 spec 2.15.2:
"Linking will also fail [...] if the program object contains objects to form a
geometry shader, and the value of GEOMETRY_VERTICES_OUT_ARB is zero."

Reviewed-by: Paul Berry <stereotype441@gmail.com>

TODO: May not be necessary for GLSL 1.50 style geometry shaders.  Make a test to validate.
!UPSTREAM: mesa: fix transform feedback when a geometry shader is active

TODO: test
!UPSTREAM: Fix up GS handling of gl_ClipDistance/gl_ClipVertex linkage rules.

TODO:
- Test
- Squash
!UPSTREAM: make stuff safe to include from C++

TODO:
- Split
i965: Initialize all elements of ctx->ShaderCompilerOptions

Otherwise any GS that requires lowering (e.g. one that uses
gl_ClipDistance or gl_ClipDistanceIn) will fail to work.
i965: Stop including brw_vs.h from brw_vec4.h

This is backwards from what we are going to want in the long term, which is:

- brw_vec4.h declares general-purpose vec4 infrastructure needed by
  both VS and GS
- brw_vs.h includes brw_vec4.h and adds VS-specific parts.
- brw_gs.h includes brw_vec4.h and adds GS-specific parts.

Note that at the moment brw_vec.h contains a fair amount of
VS-specific declarations--I plan to address that in a later patch.
!UPSTREAM: i965/vec4: Allow for dispatch_grf_start_reg to vary.

Both 3DSTATE_VS and 3DSTATE_GS have a dispatch_grf_start_reg control,
which determines the register where the hardware delivers data sourced
from the URB (push constants followed by per-vertex input data).

For vertex shaders, we always set dispatch_grf_start_reg to 1, since
R1 is always the first register available for push constants in vertex
shaders.

For geometry shaders, we'll need the flexibility to set
dispatch_grf_start_reg to different values depending on the behvaiour
of the geometry shader; if it accesses gl_PrimitiveIDIn, we'll need to
set it to 2 to allow the primitive ID to be delivered to the thread in
R1.

This patch eliminates the assumption that dispatch_grf_start_reg is
always 1.  In vec4_visitor, we record the regnum that was passed to
vec4_visitor::setup_uniforms() in prog_data for later use.  In
vec4_generator, we consult this value when converting an abstract
UNIFORM register to a concrete hardware register.  And in the code
that emits 3DSTATE_VS, we set dispatch_grf_start_reg based on the
value recorded in prog_data.

This will allow us to set dispatch_grf_start_reg to the appropriate
value when compiling geometry shaders.  Vertex shaders will continue
to always use a dispatch_grf_start_reg of 1.

TODO:
- Move into the proper part of the series.
!UPSTREAM: i965/vec4: Virtualize setup_payload instead of setup_attributes
i965: Add brw->geometry_program
!UPSTREAM: i965: Add an opcode for doing a URB write with an offset from a register (needed for GS).
!UPSTREAM: i965: Add GS_OPCODE_THREAD_END

TODO:
- Verify that I'm returning the correct value from implied_mrf_writes() for this new opcode.
i965/gs: Add GS_OPCODE_SET_WRITE_OFFSET
i965/gs: Add GS_OPCODE_SET_VERTEX_COUNT
!UPSTREAM: i965/gs: add GS visitors
i965: Make some files safe to include from C
i965: Make prim_to_hw_prim accessible outside brw_draw.c.

We will need access to this array in order to configure the geometry
shader.