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 on purpose.

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.