Compact chunk updates, for full blocks from server instead of delta

[satoshinm]

From the original Craft readme, https://github.com/fogleman/Craft#database:

Only the delta is stored, so the default world is generated and then the user changes are applied on top when loading.

and the server sends deltas using the B, command. But to decouple the client terrain from the server terrain, it would be useful to instead change this to have the server send all of the blocks. To do this efficiently, ought to support a packed chunk format, as compact as possible (not B,p,q,x,y,z,w for each block - mass block chunk updates).

[satoshinm]

Compact chunk updates may help address the problem described in today's review on https://www.spigotmc.org/resources/websandboxmc.39415/ "The only pitfall Ive come across though is the high amount of resource consumption Ive noticed it takes up. (Depending on your render radius mind you) Mine was set to 100 and it rose my 6GB RAM from 30% usage up to 65%"

[satoshinm]

ThinkMap sends chunks data like this: https://github.com/satoshinm/ThinkMap/blob/75fec8c065a7b83ec723cff99336c10368b431ad/bukkit/src/main/java/uk/co/thinkofdeath/thinkcraft/bukkit/world/ChunkManager.java#L210-L254 - world.getChunkAt(x, z) then on the Chunk object, getChunkSnapshot(): https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/Chunk.html#getChunkSnapshot-boolean-boolean-boolean-. This looks appropriate: https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/ChunkSnapshot.html "Purpose is to allow clean, efficient copy of a chunk data to be made, and then handed off for processing in another thread (e.g. map rendering)"

[satoshinm]

Using a short for future expansion (16-bit blocks: #55), so far writing the web block types to a buffer and compressing it, a nice savings - to do: send it

23:59:16 [INFO] [WebSandboxMC] uncompressed: 65536
23:59:16 [INFO] [WebSandboxMC] gzip'd: 3031

[satoshinm]

Added in #173