glsl: Fix incorrect pattern matching in ir_set_program_inouts

In commit 8fc41df (glsl: Modify ir_set_program_inouts to handle
geometry shaders), when attempting to pattern match the "foo" part of
expressions

   foo[i][j]
   foo[i]

I incorrectly called as_dereference_variable() on the subexpression
foo[i] instead of foo.  As a result, the pattern never matched, so
ir_set_program_inouts would fall back on marking the entire variable
as used, rather than just the portion indexed by the array.

This didn't result in incorrect behaviour, but it could have resulted
in inefficiency by causing the back-end to allocate resources for
unused parts of an input or output array.
i965/fs: Re-use output 0 for outputs without a static write.

According to section 15.2.3 (Shader Outputs) of the GL 4.4 spec (and
similar text in older GL specs), failing to write to gl_FragData[n]
results in undefined data being sent to color buffer attachment n:

    "Writing to gl_FragColor specifies the fragment color (color
    number zero) that will be used by subsequent stages of the
    pipeline. Writing to gl_FragData[n] specifies the value of
    fragment color number n. Any colors, or color components,
    associated with a fragment that are not written by the fragment
    shader are undefined."

Prior to commit 6a2baf3 (glsl/linker: Make update_array_sizes apply to
just uniforms), if a fragment shader only wrote to gl_FragData[0], by
a lucky coincidence the data would be replicated to all color buffer
attachments.  Proprietary drivers for AMD and NVIDIA seem to have this
behaviour too, and at least one app (Dota 2) relies on it.

It is not all that surprising that an app writer might assume
gl_FragData[0] would behave this way, since for all intents and
purposes, gl_FragData[0] behaves like gl_FragColor, and gl_FragColor
*does* get replicated to all color buffer attachments.

So let's go ahead and implement this behaviour for i965 as well.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67887
main: Fix deprecation of glLineWidth()

From section E.1 (Profiles and Deprecated Features of OpenGL 3.0)
of the OpenGL 3.0 spec:

    "LineWidth is not deprecated, but values greater than 1.0
    will generate an INVALID VALUE error"

From context it is clear that values greater than 1.0 should only
generate an INVALID VALUE error in a forward-compatible context.

The code was correctly quoting this spec text, but it was disallowing
all line widths in forward-compatible contexts, instead of just widths
greater than 1.0.

This patch introduces the correct check, so that setting a line width
of 1.0 or less is permitted.