Fast chunk loading/generation

[ah-OOG-ah]

The vanilla server attempts to load every chunk in render distance of the player, every tick. This is "fine" at low player counts, render distances, or both, but Angelica can bump that up from 16 to 32 per player, or 33^2 = 1089 chunks/player to 65^2 = 4225 chunks per player, grinding the loader to a halt (not to mention the generator...)

This branch is a WIP fix, which attempts to get around this in two ways:

• First, it breaks up chunkloading from a largely single-threaded pipeline to a pseudo-multithreaded pipeline. Reading chunks from disc and constucting them in memory is done on worker threads, much like Forge's existing but for some reason almost completely unused async pipeline. Adding those chunks to the world and doing tasks like decorating + "catch-up" ticking entities is done on another thread, and generating the base perlin noise + a couple other tasks is on yet another. Once the system is further stress-testing and reworked, it's possible to properly multithread these tasks too, it'd just require an Angelica-like effort with going through every offending modded worldgen and making it threadsafe (and ideally non-cascading while we're at it)
• Second, it overhauls how chunks are sent to the player. Vanilla can just plot a square around the previous position, a square around the current position, and send every chunk in the latter but not the former. However, if we can't generate chunks fast enough, sending them to the player will cause "holes" in the player's view that never get filled in. Thus, we keep track of the sent chunks in a set, and send any chunks in render distance but not in that set. This should work in theory, but in practice causes mad chunk rebuilding across half the render distance - weird, as that should only happen if you resend a chunk the client already has.

Current leads:

• Should empty chunks be sent instead of just not sending ungenerated chunks?
• Is there weird code on the client's recieving side?
• How does modern handle it? (this one is potentially traumatic according to embeddedt, proceed with caution)

I won't have time to deal with this for a little while, feel free to sync this branch with master or pick it up yourself.