mesa: refactor _mesa_compute_max_transform_feedback_vertices from i965.

Previously, the i965 driver contained code to compute the maximum
number of vertices that could be written without overflowing any
transform feedback buffers.  This code wasn't driver-specific, and for
GLES3 support we're going to need to use it in core mesa.  So this
patch moves the code into a core mesa function,
_mesa_compute_max_transform_feedback_vertices().

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

v2: Eliminate C++-style variable declarations, since these won't work
with MSVC.
mesa/gles3: Generate error on DrawElements* calls if transform feedback active.

In GLES3, only glDrawArrays() and glDrawArraysInstanced() calls are
allowed when transform feedback is active.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa/gles3: Generate error on draw call if transform feedback would overflow.

In desktop GL, if a draw call would cause transform feedback buffers
to overflow, the draw call should succeed, and the extra primitives
should simply not be recorded in the transform feedback buffers.

In GLES3, however, if a draw call would cause transform feedback
buffers to overflow, the draw call is supposed to produce an
INVALID_OPERATION error and no drawing should occur.

This patch implements the GLES3-required behaviour.

Fixes GLES3 conformance test "transform_feedback_overflow.test".

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: Fix corner cases of BindBufferBase with transform feedback.

This patch implements the following behaviours, which are mandated by
the GL 4.3 and GLES3 specs.

1. Regarding the GL_TRANSFORM_FEEDBACK_BUFFER_SIZE query: "If the
   ... size was not specified when the buffer object was bound
   (e.g. if it was bound with BindBufferBase), ... zero is returned."
   (GL 4.3 section 6.7.1 "Indexed Buffer Object Limits and Binding
   Queries").

2. "BindBufferBase binds the entire buffer, even when the size of the
   buffer is changed after the binding is established. It is
   equivalent to calling BindBufferRange with offset zero, while size
   is determined by the size of the bound buffer at the time the
   binding is used."  (GL 4.3 section 6.1.1 "Binding Buffer Objects to
   Indexed Targets").  I interpret "at the time the binding is used"
   to mean "at the time of the call to glBeginTransformFeedback".

3. "Regardless of the size specified with BindBufferRange, or
   indirectly with BindBufferBase, the GL will never read or write
   beyond the end of a bound buffer. In some cases this constraint may
   result in visibly different behavior when a buffer overflow would
   otherwise result, such as described for transform feedback
   operations in section 13.2.2."  (GL 4.3 section 6.1.1 "Binding
   Buffer Objects to Indexed Targets").

Item 1 has been part of the spec all the way back to the inception of
the EXT_transform_feedback extension.  Items 2 and 3 were added in GL
4.2 and GLES 3.

Prior to GL 4.2, in place of items 2 and 3, the spec simply said
"BindBufferBase is equivalent to calling BindBufferRange with offset
zero and size equal to the size of buffer."  For transform feedback,
Mesa behaved as though this meant "...equal to the size of buffer at
the time of the call to BindBufferBase".  However, this was
problematic because it left it ambiguous what to do if the buffer is
shrunk between the call to BindBuffer{Base,Range} and the call to
BeginTransformFeedback.  Prior to this patch, Mesa's behaviour was to
try to write beyond the end of the buffer, likely resulting in memory
corruption.  In light of this, I'm interpreting the spec change as a
clarification, not an intended behavioural change, so I'm making the
change apply regardless of API version.

Fixes GLES3 conformance test transform_feedback2_pause_resume.test.

Cc: Eric Anholt <eric@anholt.net>
mesa: Make a function is_transform_feedback_active_and_unpaused.

The rather unweildy logic for determining this condition was repeated
in a large number of places.  This patch consolidates it to a single
inline function.

Cc: Ian Romanick <ian.d.romanick@intel.com>