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().  Fixed some signed/unsigned comparison warnings.
st/mesa, glsl_to_tgsi: add support for geometry shaders

Note (Paul Berry <stereotype441@gmail.com>): I'm not sure I rebased
this correctly.  It appears that some amount of 2D array support was
added to tgsi after the patch was originally written.
WIP: make vec4_visitor::vp more generic
WIP: clean up uses of prog_data.
WIP: split brw_vs_compile out to brw_vec4_compile
WIP: split brw_vs_prog_key
WIP: split brw_vs_prog_data
WIP: make vec4_vs_visitor class
WIP: extract virtual functions from ir_variable visitor

Includes making a new function to handle variables of type
ir_var_system_value, which has different meanings in VS and GS.

The following functions have been renamed to reflect their generic
purpose, rather than their VS-specific behaviour:

- emit_attribute_fixups() -> emit_prolog()
- emit_vertex_program_code() -> emit_program_code()
- emit_urb_writes() -> emit_thread_end()
WIP: move VS-specific functions to vec4_vs_visitor
WIP: move VS-specific data members to vs_vec4_visitor.

This required making some new data members in the base class to point
to generic data structures.
WIP: Generalize data structures pointed to by vec4_generator.

vec4_generator never used the vertex-shader-specific parts of these
data structures anyway.
WIP: rename vec4_generator::generate_vs_instruction
WIP: make stuff safe to include from C++
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.
WIP: i965: Add an opcode for doing a URB write with an offset from a register (needed for GS).
i965/vs: Generalize vertex emission code in preparation for GS.

This patch introduces a new function, vec4_visitor::emit_vertex(),
which contains the code for emitting vertices that will need to be
common between the vertex and geometry shaders.
i965/vs: Generalize attribute setup code in preparation for GS.

This patch introduces a new function,
vec4_visitor::lower_attributes_to_hw_regs(), which replaces registers
of type ATTR in the instruction stream with the hardware registers
that store those attributes.  This logic will need to be common
between the vertex and geometry shaders.
i965/vs: Generalize computation of array strides in preparation for GS.

Geometry shader inputs are arrays, but they use an unusual array
layout: instead of all array elements for a given geometry shader
input being stored consecutively, all geometry shader inputs are
interleaved into one giant array.  As a result, the array stride we
use to access geometry shader inputs must be equal to the size of the
input VUE, rather than the size of the array element.

This patch introduces a new virtual function,
vec4_visitor::compute_array_stride(), which will allow geometry shader
compilation to specialize the computation of array stride to account
for the unusual layout of geometry shader input arrays.  It also
renames the local variable that the ir_dereference_array visitor uses
to store the stride, to avoid confusion.
i965: Generalize computation of VUE map in preparation for GS.

This patch modifies the arguments to brw_compute_vue_map() so that
they no longer bake in the assumption that we are generating a VUE map
for vertex shader outputs.  It also makes the function non-static so
that we can re-use it for geometry shader outputs.