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.
WIP: add GS visitors