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 differ 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.
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
i965: Move brw_vs_prog_data::outputs_written into VUE map.

Future patches will allow for there to be separate VUE maps when both
a geometry shader and a vertex shader are in use.  When this happens,
we will want to have correspondingly separate outputs_written
bitfields.  Moving outputs_written into the VUE map will make this
easy.

For consistency with the terminology used in the VUE map, the bitfield
is renamed to "slots_valid" in the process.
WIP: i965: Create a pointer in brw_context to the geometry output VUE map.

Currently, the GPU pipeline has one active VUE map in effect at any
given time--the one representing the layout of vertex data coming from
the vertex shader.  However, when geometry shaders are added, they
will have their own independent VUE map.  Later pipeline stages (clip,
sf, fs) will need to consult the geometry shader VUE map if a geometry
shader is in use, and the vertex shader VUE map otherwise.

This patch adds a new field to brw_context, vue_map_geom_out, which
points to whichever VUE map should be used by later pipeline stages.
It also adds a new state flag, BRW_NEW_VUE_MAP_GEOM_OUT, which is
signalled whenever this pointer changes.

Since we don't support geometry shaders yet, vue_map_geom_out is
currently set only by the brw_vs_prog state atom.
i965: Use brw.vue_map_geom_out instead of VS output VUE map where appropriate.

This patch modifies post-GS pipeline stages (transform feedback, clip,
sf, fs) to refer to the VUE map through brw->vue_map_geom_out rather
than brw->vs.prog_data->vue_map.  This ensures that when geometry
shader support is added, these pipeline stages will consult the
geometry shader output VUE map when appropriate, rather than the
vertex shader output VUE map.
i965/fs: Rename vp_outputs_written to input_slots_valid.

With the introduction of geometry shaders, fragment inputs no longer
come exclusively from the vertex shader; sometimes they come from the
geometry shader.  So the name "vp_outputs_written" becomes a misnomer.
Renamed to reflect the true meaning of the bitfield from the fragment
shader's point of view: it indicates which of the possible input slots
contain valid data that was written by the previous shader stage.
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: add GS visitors