TGEA1.8.0 LightManager's late initialization bug

I've found a potential dangerous behavior with LightManager deferred initialization performed when calling SceneGraph::getLightManager() in the TGEA 1.8.0.

My levels that worked fine for 1.7.1 in 1.8.0 crushed engine at random sections of code.
The problem was in the "wrong" place of the sun object in the *.mis file.
When sun is placed _before_ shapes it works as usual, but when sun object is placed after
shapes or absent at all the engine will probably crush because of memory corruption.

That's what happening:
1) Shape object trying to create material list for it's shapes instance.
2) Shape instance calls TSShapeInstance::setMaterialList to activate materials for the shape.
3) Then instances of materials are creating, and in ProcessedMaterial::_initPassStateBlock will
call gClientSceneGraph->getLightManager();
4) If LightManager haven't yet been initialized it will do this, and calls MaterialManager::get()->reInitInstances(); from SceneGraph::setLightingSystem(). This will simply delete all created materials including the very same material from 3) that initiated getLightManager call. The result will be a bad memory corruption.

To fix this problem we need to make sure that gClientSceneGraph->getLightManager() will be called before any TSShapeInstance and other material creations. I've done this right in TSShapeInstance constructor.

TSShapeInstance::TSShapeInstance(const Resource<TSShape> & shape, bool loadMaterials)
{

........... skipped..........

   //.hack >> make sure we've LightManager initialized
   if(gClientSceneGraph)
	gClientSceneGraph->getLightManager();
   //.hack << 

   buildInstanceData(mShape, loadMaterials);
}