EMI: Implement lighting for OpenGL and TinyGL renderers

This implements lighting for EMI.

The lighting is calculated in software, because the attenuation model used by EMI can't be accurately simulated with the OpenGL fixed function pipeline. I think this solution is acceptable for TinyGL and old OpenGL, but for the shader-based OpenGL renderer it would be a better idea to use a shader. I wrote about this in http://akzgsoc.blogspot.fi/2014/06/lighting-first-results.html.

The lighting model looks like the LIGHT_NORMDYN (normal dynamic) lighting mode in the original. In the original there is also a LIGHT_FASTDYN mode that looks slightly different since it produces a less accurate result. I think the NORMDYN mode can be considered visually superior, so I did not try to replicate the look of FASTDYN mode in this PR.

The result matches the original game almost exactly in all the sets I've tested it in. Most differences that can be seen are due to the inaccuracy of the FASTDYN lighting mode in the original.

6c06ef1 adds simple view frustum culling. If a model's bounding box is not in the view frustum, lighting is not calculated and no draw commands are passed to the renderer. This commit is not strictly necessary for this PR, but it is a noticeable performance optimization in large sets where there may be a number of models active but only a few of them are in view at a time. The frustum culling could be used to improve performance in Grim as well.
... and either change the 1 and 2 to direct enum-usage, or simply call actor->setLightMode(lightMode), as the constants are mapped to what we get from LUA anyhow?

The current layout is a bit over-complicated without reason anyhow, we have 3/4 cases being simply actor->setLightMode(lightMode), with only LightNone being the different one, so how about:

if (lightMode == Grim::Actor::LightNone) {
     actor->setGlobalAlpha(0.0f);
     actor->setAlphaMode(Grim::Actor::AlphaReplace);
}
actor->setLightMode(lightMode)?

Or, does this get weird, as we'd then be passing an int instead of mapping the enum?

Either way, the nested ifs are unneccessary.