Small optimisations.

# Description:
Profiling showed that we were spending a lot of CPU time in LMR, 87% in the tests I was running with a modifed "Hometowns" mod. However further investigation showed that a lot of it was due to time spent querying the OpenGL context.

Some of these issues cannot be fixed trivially in LMR due to the way it's structured, it doesn't form a natural or graph that can be traversed without extending the renderer in odd ways so transformations can't be tracked and cached. SGModel doesn't have this problem and only needed an optimisation in RenderLegacy, which the LmrModel path shares, to avoid the performance penalty.

## The optimisations:
There are two main optimisations they are:

### Avoid rebuilding the frustum:
The first is simply to avoid rebuilding the frustum from OpenGL when we already have it within the camera passed into CityOnPlanet. I found this whilst I'd disabled all LmrModel rendering entirely and it was the hungriest call left. Sadly I didn't save the profile capture of it. There's another call like it in GeoSphere::Render but I'm leaving that alone for this PR.

### Avoid querying OpenGL context state:
The second optimisation is to store the matrix passed into RendererLegacy::SetTransform so that it can be read in DrawPointSprites and thus avoid querying the OpenGL modelview matrix which was accounting for 41% of CPU frame time in just 22 calls. This optimisation means that SGModel shouldn't suffer any OpenGL queries down this render path. However LmrModel still will because it uses the OpenGL matrix transformation stack.

# Conclusion:
The sooner LmrModel goes away, the sooner we can run the "Hometowns" mod, with all cities enabled, at 60fps with CPU time to spare.