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.
Ok, let me rephrase to see if I understood it right:
* Valid For Renderering = the chunk *AND* its adjacent chunks are ready.
* Ready = the chunk is availalable through the chunk provider AND light has propagated to it AND valid meshes have been generated for it.
* dirty = the chunk needs to have its meshes regenerated.

Also in this context:
* what can leave a chunk with a pendingMesh? The methods in this part of the code seem to eventually always set chunk.pendingMesh to null, but checks are made, i.e. in updateAndQueueVisibleChunks(), to verify if there are pending meshes in a chunk. 
* why is the ChunkProvider update process split over more than one tick/frame in a "completeUpdate" first and in a "beginUpdate" afterwards?