glsl: Emit better warnings for things that look like default precision statements

Previously we would emit a warning for empty declarations like

float;

We would also emit the same warning for things like

highp float;

However, this second case is most likely the application trying to set
the default precision.  This makes the compiler generate a stronger
warning with some suggestion of a fix.

It really seems like this should be an error.  I'll bet that 100% of the
time someone writes 'highp float;' the actually meant 'precision highp
float;'.  Alas, both AMD and NVIDIA accept this syntax, and the spec
doesn't explicitly forbid it.

This makes piglit's precision-05.vert generate the following warnings:

0:12(11): warning: empty declaration with precision qualifier, to set the default precision, use `precision lowp float;'
0:13(12): warning: empty declaration with precision qualifier, to set the default precision, use `precision mediump int;'

v2: Add { } around a one-line if body and fix a comment.  Suggested by
Ken.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
vl: Add support for max level query v2

This patch adds the level query support to the video decoders
and uses some more reasonable defaults.

v2: (ck) add commit message

Reviewed-by: Christian König <christian.koenig@amd.com>
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 such as:

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

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67887