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.
Actually, it's stranger than that. If I write some code such as:
`renderableRegionSize.x /= 2;` or `renderableRegionSize.x = renderableRegionSize.x / 2;`
it will generate the same problem: a mostly empty world, with only the skysphere in sight and some geometry visible only through the diagnostic display given by the F5/F6 buttons. 
Interestingly, this happens even if one of those lines are **after** the "renderableRegionExtent" declaration. So, at this stage I don't really have a clue of what's happening. I haven't checked the content of these variables at runtime though. I have to get acquainted with IntelliJ debugger. For now let's not worry about it: like this it works.