intel/pre-gen6: Disable EXT_framebuffer_multisample.

Previously, the i965 driver enabled EXT_framebuffer_multisample even
on pre-gen6 chipsets.  However, since we don't support multisampling
on these chips, we set GL_MAX_SAMPLES=1 (the minimum allowed by
EXT_framebuffer_multisample), and if the client ever requested a
multisample buffer, we quietly supplied them with a single-sampled
buffer instead.

After some discussion on the mailing list (see thread
"ext_framebuffer_multisample: check for num_samples<=1"), it's clear
that this was the wrong approach.  The correct approach is to only
expose EXT_framebuffer_multisample when we truly support
multisampling; that frees us to set a sensible value of
GL_MAX_SAMPLES=0 on other chipsets, so that we never have to deal with
a client requesting a multisample buffer when multisampling isn't
supported.

This change causes the following piglit tests to be skipped on
chipsets prior to Gen6:

- "ARB_framebuffer_sRGB/blit {renderbuffer,texture}
  {linear,linear_to_srgb,srgb,srgb_to_linear}
  {downsample,msaa,upsample} {disabled,enabled}"
- EXT_framebuffer_multisample/blit-mismatched-formats
- EXT_framebuffer_multisample/blit-mismatched-sizes
- EXT_framebuffer_multisample/dlist
- EXT_framebuffer_multisample/interpolation 0 *
- EXT_framebuffer_multisample/minmax
- EXT_framebuffer_multisample/negative-copypixels
- EXT_framebuffer_multisample/negative-copyteximage
- EXT_framebuffer_multisample/negative-max-samples
- EXT_framebuffer_multisample/negative-mismatched-samples
- EXT_framebuffer_multisample/negative-readpixels
- EXT_framebuffer_multisample/renderbuffer-samples
- EXT_framebuffer_multisample/renderbufferstorage-samples
- EXT_framebuffer_multisample/samples

This is expected, since the above tests exercise MSAA functionality,
and shouldn't be run on systems prior to Gen6.

Reviewed-by: Eric Anholt <eric@anholt.net>
Consolidate some redundant definitions of ARRAY_SIZE() macro.

Previous to this patch, there were 13 identical definitions of this
macro in Mesa source.  That's ridiculous.  This patch consolidates 6
of them to a single definition in src/mesa/main/macros.h.

Unfortunately, I wasn't able to eliminate the remaining definitions,
since they occur in places that don't include src/mesa/main/macros.h:

- include/pci_ids/pci_id_driver_map.h
- src/egl/drivers/dri2/egl_dri2.h
- src/egl/main/egldefines.h
- src/gbm/main/backend.c
- src/gbm/main/gbm.c
- src/glx/glxclient.h
- src/mapi/mapi/stub.c

I'm open to suggestions as to how to deal with the remaining redundancy.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Fix unsupported version error for GLSL ES 3.00, future proof for 3.30.

When the user specifies an unsupported GLSL version,
_mesa_glsl_parse_state::process_version_directive() nicely gives them
an error message telling them which GLSL versions are supported.
Previous to this patch, the logic for determining whether a given
language version was supported was independent from the logic to
generate this error message string; as a result, we had a bug where
GLSL 3.00 would never be listed in the error message as an available
language version, even if it was really available.

To make matters worse, the code for generating the error message
string assumed that desktop GL versions were always separated by 0.10,
an assumption that will be wrong as soon as we support GLSL 3.30.

This patch fixes both problems by adding a table of supported GLSL
versions to _mesa_glsl_parse_state; this table is used both to
generate the error message and to check whether a given version is
supported.
WIP: don't allow non-flat varying structs containing integral types.

May also fix problems with varying arrays of non-ints, need to check for sure.

I don't want to send out this patch until we've resolved the question
of whether Mesa should be checking this on vertex shader outputs,
fragment shader inputs, or both.