Fix unnecessary mmap'ing of compass .dat files

[szuend]

Fixes #595.

The access of the compass/*.dat files is currently broken. During chunk generation we easily mmap the same .dat file (1 MB each) thousands of times, leading to OOMs if the VM/OS doesn't unmap fast enough during GCs.

The access to the compass/*.dat files is synchronized via a single "Compass Service" thread. The CompassService class posts job tasks to this thread. The current idea is that when each task finishes, it checks whether more tasks are queued up, and if not, unmap the .dat file. There are two main issues:

1. The job accounting is plain broken. The CompassServide.#jobSize grows only into the negative (due to some missing jobSize++). This means that we un-map all .dat files after each job even if more jobs are queued up.
2. If jobs are scheduled a couple milli seconds apart, we'd still un-map and then re-map the .dat file.

This PR fixes this by removing the the broken job accounting all-together and replaces it with a per dimension timeout: If a .dat file goes unused for 60 seconds, we'll unmap it.

Local testing shows that we go from around ~10k map/unmap operations to 4 when generation a new SP world (with boosted meteor generation chances so I don't have to go looking).

Implementation details

The PR achieves this by adding a new AutoClosingCompassReader class. It is associated with a single CompassReader that needs to be retrieved via AutoClosingCompassReader#get. Ever time get is called, we schedule a delayed "closing task". If one is already schedule when get is called, we'll cancel it.

[serenibyss]

This looks like a great improvement, thanks!