Background thread for area loading, optimizations, bugfixes

Finally after two previous attempt to realize a working and fast parallel load of map I have succeeded. Now a separate thread is starting to load the area when you reach the middle of the previous render distance, so while you keep walking around it will load the things and with high chance you won't reach the limit of loaded area before the load of the newly needed area finishes in the background thread. It generally doesn't happen yet the rendering is prepared for that, if you reach the limit the background thread is stopped and a new foreground loading starts halting you walk. But this case happens really rarely if you selected the right level of detail for your PC's performance. Thus you will be able to walk freely without pauses with a dynamic background loading - in the next release that will come. Or if you check out the latest SVN you can test it right now.

Bugs...Long lurking culling problem of tree foliage now I could eliminate - GeometryBatchMesh spatial instance needed a buildMatrices to have the correct world rotation before being locked. Also I could fix some other annoying bugs - foliage of bushes rendered at high above the trunk sometimes and texturestate vegetations were wrongly repositioned while you walked around (both problems were related to reuse and wrong modification of position vectors).

A new RenderedArea implementation was born to fasten the loading of area - and it was a successful rewrite! Now it's 3 or 4 times or even 8 times faster than before in some cases. It includes a smarter calculation of areas to newly load and to remove. It calculates the newly needed and removable areas based on the disposition to the last rendered location vector. The other big thing was to define and implement a new getFilledZonesOfY for the Place superclass. Every Place extension (Geographies, Economics, Waters, etc.) now tells what Y height intervals are parts of them at a given X/Z location of the World. The information is collected and combed together and is used to determine what Y intervals to include in RenderedArea's rendering. This way about 4 or 5 times less World.getCube call is needed - only the really filled cubes are being requested by the loading process, empty positions are skipped. Naturally this leads to a much better loading time because of the nature how a world's surface is only consisting of a few cubes height even considering economic upon them.

Cool! :) Listing the things done since starting the optimization session: much more stable memory use (less overall memory needed), continuous appending of 3D scenario, background process for loading areas with no pauses, important bugfixes, better 3D performance/loading times.