Distorted Android

Port some obvious stuff from OIT branch.

I am pretty sure this time the flashing issues on Mali T880 r12 driver are finally fixed.

The fix: a queue of FBOs render to, just like before, but this time in DistortedScreen we blit not the current FBO, but the one computed several frames ago.

This of course introduces a delay and uses more memory, but it appears to work and does not seem to have any effects on speed.

I spoke too soon, the ARM Mali flashing is of course not fixed yet. The previous commit fixed Triblur, but the bug is still reproducible elsewhere (only in the 'postprocessed' apps though).

This commit introduces a circular queue in case of the postprocessing FBOs - with little success though.

Finally properly fix the flashing on ARM Mali T880 GPU.

The flashing is caused by a 'full pipeline flush' (see DarkPhoton, https://www.opengl.org/discussion_boards/showthread.php/200754-Flashes-on-ARM-Mali?p=1291679&viewfull=1#post1291679 ). In order to combat it, first introduce the possibility that a single DistortedOutputSurface is backed up by more than one FBO. Then make DistortedScreen be derived from DistortedFramebuffer (which itself is derived from DistortedOutputSurface) and make it contain 3 FBOs, render to them in a circular queue fashion, and blit from a given FBO to the system FBO. The 'more than 1 intermediate FBO' queue prevents the pipeline flush....

Minor.

Port all the 'non-controversial' changes from order-independent-transparency branch.

Fixes ported from the 'OIT' branch:

- remove counting of transparent pixels
- various fixes for the Mali GPU

Disable blending during postprocessing.

Fix for bug #28: looks of the borders of a blurred object depend on if the object is the first in the postprocessing bucket.

Postprocessing buffers mBuffer[] are now shared among all postprocessing operations. This saves a lot of memory, but also means that when doing each particular postprocessing, the textures backing up the mBuffer might be too large. We need to fix two things here: when outputting to those too large textures, we need to adjust the Viewport, and when binding those too large textures as input - we need to adjust the TexCoords to compensate....