Per pixel lighting support in Metal

[colincornaby]

This PR adds Metal per pixel lighting support to the shaders - controlled by a preprocessor flag. Per pixel lighting defaults to off in since it's an alternative rendering mode that does not match the original engine. While per pixel lighting seems correct - it should be regarded as experimental. Per pixel shading enables a shader variant for the "fixed" pipeline shader. This shader variant is controlled by a shader compile time flag. However - this flag is a function constant which means evaluation of it can be deferred to when the shader is compiled from Metal byte code into vender specific assembly. I.E. - Metal can wait to apply the flag until the final runtime shader compilation.

Metal was originally ported from the OpenGL fork which used per pixel lighting. Metal switched back to per vertex for several reasons:

• The fragment shader function was trying to emulate the Direct3D fixed function pipeline - and because of high register usage was running into a lot of register overflows. The additional registers required by per pixel rendering was causing extreme performance issues. The shader has moved most of this register usage into compile time constants - so there are enough registers free now to do per pixel lighting.
• Most of Uru uses lower complexity meshes or light maps. Bump mapping was never in Uru. So the benefits of per pixel lighting were less - and per pixel lighting was deprioritized.

Please look over this closely - I want to make sure the per vertex path has remained unchanged. Not in a rush to get this in.

[colincornaby]

I brought this branch up to date with master - and now it's acting strangely. For example - it's hitting asserts while trying to load the server.ini. I'll dig a bit and see whats going on. I'm pretty sure this behavior is newly unique to this branch. Last time I was in here it was working.

[colincornaby]

The issue I was befuddled by is addressed in #1591.

[dpogue]

FWIW I'm pretty sure OpenGL is also doing per-vertex lighting to match DirectX.

I might have been doing that in the fragment shader at one point while I was getting it set up, but it's in the vertex shader in the current version of the GL branch.

[colincornaby]

Re-stating discussions elsewhere here for the status on this branch.

• While evaluating the lighting pipeline - it was found Metal is not properly handling the bump maps.
• Plasma calls them "bump maps" but they actually seem to be normal maps.
• Normal maps typically require per pixel lighting. In the D3D renderer there is a algorithm that attempts to bake the lighting algorithm into the texturing pipeline.
• This algorithm has significant issues - but would have been a reasonable approximation in the early 2000s.

Relative to this PR:

• We're not going to reimplement Cyan's algorithm in Metal. We have the ability to do proper normal mapping on Metal hardware.
• We will not ship per pixel lighting by default - but meshes can opt into it.
• Meshes with normal mapping will be opted into per pixel lighting. A normal mapping path in the shaders will be implemented in a future PR.
• The Metal pipeline will render normal maps differently than Windows - but the quality should be much higher.

We'll want to move ahead with this PR to get normal mapping into Metal.