requestChunkPopulation() respects the queue size, orderChunkPopulation() does not.
requestChunkPopulation() should be used for non-essential generation (which mainly includes generation for player use).
orderChunkPopulation() should probably be used by plugins.
it's now the World's responsibility to manage adding/removing entities from appropriate chunks. Entities no longer know or care that chunks exist.
Entity->checkChunks() remains as-is for backwards compatibility - now it just calls the world to sync its position.
if a PopulationTask took place after the target worker was garbage collected, the population would fail and the chunks it used would be copied for nothing.
This change marks workers as having unregistered generators when detecting that a worker that previously had a generator registered is restarted.
a non-generated chunk is now always represented by NULL. This forces the case of ungenerated chunks to be handled by all code, which is necessary because ungenerated chunks cannot be interacted with or modified in any meaningful way.
this only made sense to work around the server crashing when creating a player in ungenerated terrain, but spawning at y=256 is hardly preferable, and it'll crash since fd99445c5b anyway ...
instead, it will fire when the chunk comes out of PopulationTask and is set into the world using setChunk().
There is still one place left where auto-creation of empty chunks is used by the core, and that's an issue i'm still deciding how to deal with.
I'm of two minds whether this should continue to fire onChunkChanged() on chunk loaders or not, since the chunks won't be referenced by any chunk loader anyway by virtue of not existing ...
instead of being forced to use the Server async pool
right now the intent of this is to reduce (and ultimately eliminate) the dependency of World on Server, but it might come in useful for other stuff too, for example a chunkserver-based generator implementation which blocks on network instead of eating CPU (it would just waste CPU for other tasks).
this restores SimpleChunkManager's behaviour to PM3, removing the need for GeneratorChunkManager (although I'm dubious whether SubChunkExplorer makes any sense in there any more now that we have morton in the mix).
