Drop fixed pipeline support code

[sfan5]

continuation of #15067 (in spirit), #15210

Current situation

Shaders have been enabled by default since ~0.4.16 on desktop and 5.7.0 on Android.

Proposal

Delete all code that depends on !enable_shaders.
It's not easy to estimate how much this is but MapBlockMesh has entire data structures for doing lighting only when shaders are not used.

Why? I think it's finally time for us to free ourselves from legacy shackles.
If you pull a 10 year old computer from a dusty store room it will be able to support OpenGL with shaders. Refer also to this discussion.
There will inevitably be cases where Luanti runs better w/o shaders than with. Hopefully users will report them to us and we can try to fix them, but in many cases this is simply due to outdated hardware design (example).

This would effectively put our minimum OpenGL requirement at 2.0.

Advantages

• less and cleaner code to maintain
• less bugs that nobody notices (Fix model[] being lit wrongly if shaders are disabled #15364)
• bigger potential for optimizations to be made that require shaders
  • (theoretically possible now but in many cases we don't want to maintain two implementations of something)
• future features can be added that require shaders (e.g. Ambient light and server control for it #14343)

Concerns

• video_driver = null should be kept working for headless usage, but this is easy
• the number of negatively impacted users will be non-zero. we will have to accept this.

Note: With menu clouds relying on shaders in 5.10.0, we will be able to tell quite well from user complaints if some people really have shader-incompatible hardware.

[rubenwardy]

I support this

[appgurueu]

I used to be conflicted on this (due to the second concern), but I am not anymore. It hadn't quite dawned upon me just how extremely legacy this is. It's about time we start taking steps forward.

[sparky4]

i don't support this

sigh...

[JamesClarke7283]

i don't support this

sigh...

Why is that? I am curious.

Context:

OpenGL v2, was released as stable in 2004, more than 20 years ago.

I would also argue software moving to newer minimum versions of these libraries, might be a good way to incentivize users upgrade to newer hardware/software. The amount of 9-10 rated CVE's applicable to these kinds of hardware/software is immense, plus even buying the lowest end hardware today will outpace 20 year old hardware by a significant amount.

I realize this is merged, I just note this so any future upgrades in minimum library versions/etc take into consideration the security angle too(if not already done so), especially in the increasingly sophisticated cyber threat actors of today.