i965/gen6+: Fix multisample assertions in CopyTexSubImage hw blitter path.

Commit 045612c (intel: Add an assert for glCopyTexSubImage() being
called on MSAA buffers) added an assertion to intel_copy_texsubimage()
to make sure that multisampling was not in use, based on the
assumption that glCopyTexSubImage() can't legally be used with
multisampling.

However, there is one case where glCopyTexSubImage() can legally be
used with multisampling: when the source buffer is a multisampled
window system buffer.  If the source and destination color formats
don't match, the blorp path will fail, so intel_copy_texsubimage()
will be called.  In this case, we need intel_copy_texsubimage() to
return false so that we fall back to meta to do the copy.  (The
multisampled source buffer won't cause a problem for the meta path,
because it uses glReadPixels, which forces a multisample resolve).

It's still safe to assert that the destination image is
single-sampled, because it's not legal to call glCopyTexSubImage() on
multisampled textures.

Fixes some failures with piglit tests "copyteximage
{1D,2D,CUBE,RECT,2D_ARRAY}" (with "samples=..." argument).

Reviewed-by: Eric Anholt <eric@anholt.net>
intel: Don't try to blorp or blit CopyTexSubImage(1D_ARRAY).

Blorp and the hardware blitter can't be used to implement
CopyTexSubImage when the image type is 1D_ARRAY, because of a
coordinate system mismatch (the Y coordinate in the source image is
supposed to be matched up to the Z coordinate in the destination
texture).

The hardware blitter path (intel_copy_texsubimage) contained a perf
debug warning for this case, but it failed to actually fall back.  The
blorp path didn't even check.

Fixes piglit test "copyteximage 1D_ARRAY".

Reviewed-by: Eric Anholt <eric@anholt.net>
intel: make intel_flush_front safe to call during initial MakeCurrent

The patch that follows will fix a bug that prevents
intel_flush_front() from being called often enough.  In doing so, it
will create a situation where intel_flush_front() during the initial
call to glXMakeCurrent().  In this circumstance, ctx->DrawBuffer
hasn't been initialized yet and is NULL.  Fortunately,
intel->front_buffer_dirty is false, so intel_flush_front() doesn't
actually need to do anything.  To avoid a segfault, swap the order of
terms in intel_flush_front()'s if statement.
intel: flush fake front buffer more robustly.

When a fake front buffer is in use, if we request the front buffer
(using screen->dri2.loader->getBuffersWithFormat()), the X server
copies the real front buffer to the fake front buffer and returns the
fake front buffer.  We sometimes make redundant requests for the front
buffer (due to using a single counter to track invalidates for both
the front and back buffers), so there's a danger of pending front
buffer rendering getting overwritten when the redundant front buffer
request occurs.

Previous to this patch, intel_update_renderbuffers() worked around
that problem by sometimes doing intel_flush() and intel_flush_front()
before calling intel_query_dri2_buffers().  But it only did the
workaround when the front buffer was bound for drawing; it didn't do
it when the front buffer was bound for reading.

This patch moves the workaround code to intel_query_dri2_buffers(), so
that it happens in exactly the circumstances where it is needed.

This should fix some of the sporadic failures in Piglit tests
fbo-sys-blit and fbo-sys-sub-blit.
intel: flush fake front buffer if server is about to destroy it.

Fixes piglit test "spec/!OpenGL 1.0/gl-1.0-front-invalidate-back"