RenderableWorld changes

This PR follows #1456 and focuses only on the new class, **RenderableWorldImpl**.

The first commit ([diff 1](https://github.com/emanuele3d/Terasology/compare/MovingBlocks:develop...emanuele3d:c68febe)) mostly just renames variables and methods to improve readability.
The second commit ([diff 2](https://github.com/emanuele3d/Terasology/compare/emanuele3d:c68febe...emanuele3d:ea3a231)) does a number of things:
* extracts variable instantiation from loops when appropriate
* reviews and refactors some of the logic where appropriate (*reviewers needed!*)
* compacts some methods
* removes some duplication

The second commit also augments the RenderableChunk interface and the ChunkImpl class by adding methods hasMesh() and hasPendingMesh(). Both have been put in place to increase readibility, as they replace statements such as "if(chunk.getMesh() != null)" with "if(chunk.hasMesh())"; 

RenderableWorldImpl will be further modified when I start working on WorldRendererLwjgl.
Notice that this PR comes with some line-specific questions.

UPDATE: 
The third commit ([diff 3](https://github.com/emanuele3d/Terasology/compare/emanuele3d:ea3a231...emanuele3d:734898)) addresses the issues discussed so far, namely: private vs public static variables, static variables requiring objects from the registry made non-static, a few small changes here and there, and a slightly different handling of the camera position in the comparators, awaiting for a more complete solution in following PRs.
http://stackoverflow.com/questions/21960407/how-do-you-make-a-new-thread-in-java-with-opengl-support

Currently we're haven't delved into into multiple contexts. Even then you don't write directly onto an object being used on the main thread without some synchronization. So we could potentially move the creation of the new mesh to the background thread, given that the thread has an OpenGL context, but would still swap the old mesh for the new in the main thread. Plus we'ld need to ensure the submission to GPU was complete first. A new chunk mesh is generally not the same size, so you certainly cannot just render whatever is there - it must be an atomic switch over to a new vertex and index buffer.

Without a second context you simply cannot issue opengl commands off thread. I believe even if you were to use CPU or shared CPU/GPU memory (I believe the latter is only available for integrated GPUs?) it would cause issues if the mesh was rendered mid change, especially because the mesh does change size and you need both the vertex and index buffers changed together. My understanding is CPU memory is best for data that changes very regularly (every frame or so) or that needs to be accessed by CPU, and is otherwise best avoided - I suspect the same goes for shared memory (I haven't found much on this, except AMD/Intel extensions specific for integrated GPUs)

We target OpenGL 2.0. Performance improvement opportunities from more recent OpenGL versions are generally not so useful since performance improvements are most needed on older systems and older systems don't support newer versions of OpenGL (I hate everything about this).