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.
Concerning the private/public static variables: I do not foresee wider use. I'll make them all private for the time being. If somebody wants them from this class they can change them back to public. I'd like to see them in user-accessible settings, perhaps in a uber-duper-advanced-diagnostic-expert-only page, or even in an otherwise inaccesible-at-runtime text file. But this is not the PR to solve that kind of issue.

Concerning reading from the CoreRegistry, that's quite an overarching issue. Isn't everything in that registry only one step away from being a classic no-no global variable? Especially given exactly what you are talking about: even accessing the source code it can be difficult to track the timeline of initializations and registrations. But if somebody changes the order of things in the source, it gets discovered only at runtime. Could this be address by making sure that the CoreRegistry generates an Exception if the underlying map returns null? This would force registry-users to explicitely address the possibility and either recover or fail in meaningful way.