Compute sprite vertexes on CPU, not with GLSL

[slipher]

Get rid of the vertex sprite GLSL shader and do the autosprite vertex position calculations on the CPU side instead. This fixes various bugs with autosprite surfaces and particle sprites. To quote the message of the most important commit:

Get rid of vertexSprite_vp.glsl/USE_VERTEX_SPRITE and return to doing
deformvertexes autosprite/autosprite2 vertex calculations on the CPU
(like it was until 2015). This fixes various bugs with autosprite[2]
BSP surfaces. Also it
fixes some particle systems which were broken for unknown reasons.

One problem with the vertex sprite GLSL is that it always applied depth
fade, regardless of whether it was requested. Depth fade means the alpha
will be reduced if there is something close behind the particle within a
certain depth (judging by the z buffer). With autosprite1, this depth
parameter was set equal to the size of the sprite. So it is like a
cube-shaped cloud (which matters when part of the cloud is inside a
wall). The shader-specified fade depth, if any, was ignored. With
autosprite2, the shader used a negative depth parameter, which just
breaks everything. By removing unwanted depth fade for
BSP surfaces, this fixes #997
(non-opaque autosprite2 BSP surfaces do not show up, as seen with the
various flames on KOsAD's metro map).

Also depth fade will no longer be automatically applied to all
particles. I believe we have just 3 Unvanquished shaders configured with
depth fade: acid tube acid, booster effect, and grenade smoke. All
'cloud of gas'-type effects. Any other particles could potentially look
different due to removing depth fade. However, I have failed to notice
any (other than broken ones that started working). For small particles,
the depth fade is unlikely to make any difference.

Another issue is that USE_VERTEX_SPRITE was not available for lightmap
shaders. This meant that vertex positions were out of sync between
the generic and lightmap shaders, and the lightmap shader failed to render
anything. So this commit fixes #1246 (wrong lighting for autosprite[2]
BSP surfaces with lightmaps, as seen on map "defenxe") by calculating
the final vertex positions before uploading them, which ensures they are
the same for all GLSL shaders used.

With this commit, some particles that were previously not visible are
now rendered: the ones with the gfx/players/alien_base/green_acid shader
which are emitted upon evolving, or damaging or destroying an alien
buildable. I believe the problem must have been that Tess_AddSprite
oriented the triangles backward (CW instead of CCW or vice versa). And
unlike most particle shaders, the acid one fails to specify double-sided
culling, so it would disappear if oriented backward.

To implement CPU-side autosprite/autosprite2 transformations, I took the
code from an old (~2015) version of the file. But I ended up completely
writing the autosprite2 one.

When autosprites were first implemented in GLSL, there was also a
change in how the polygon is positioned: in the GLSL implementation it
faces towards the viewer, rather than Tremulous' behavior to face
opposite the view direction. I decided that the GLSL behavior is
superior for autosprite2 and reimplemented the CPU version that way (but
you can get the old behavior by setting the r_autosprite2Style cvar).
For autosprite the old behavior seems good enough so it once again faces
opposing the view direction.

This commit makes autosprite2 surfaces work with material system enabled
for the first time, by virtue of rendering them without using the
material system.

Not ready for detailed review as many of the commits in here are mostly unrelated and will be submitted as separate PRs. (One awaiting review is #1273).

There a couple things I would appreciate help testing:

• Help me check that all particle systems still look fine and without noticeable changes (other than some previously broken acid particles now being visible), as there a couple differences in particle handling:
  • Depth fade (aka soft particles) is no longer used for particles whose shaders don't explicitly request it. If depth fade is turned off for a particle that really needs it, it may be noticeable as a square texture clipping into a wall.
  • Orientation of particles is different.
• I would like to know if there are any maps using autosprite mode 1 (aliases deformvertexes autosprite or deformvertexes sprite) other than old versions of station15.

[illwieckz]

Awesome work, it works on my end, it even fixes the distortion of metro chain sprite. I'm not sure the lighting of the chain is correct, but that's good enough for now.

[slipher]

The code is ready for review. Still need to go through all the assets to see which particle shaders need to have depth fade added, and which ones should be nuked (because they didn't appear before and are ugly).