Speedup backups slightly + max backup folder size config

[Lyfts]

1. Switches the zip implementation from the native java one to Commons Compress which 1.7.10 ships with. After a lot of testing it showed a decent speed improvement, no clue why though since they use the same compression algorithm.

This is 10 runs on compression level 1 & DEFLATE,
The original folder was 3.65GB which was artificially inflated using copied region files.

Run #	New Time (Commons Compress)	Old Time (Native Java)
1	2:20 min	2:47 min
2	2:20 min	2:53 min
3	2:24 min	2:56 min
4	2:22 min	2:45 min
5	2:22 min	2:48 min
6	2:22 min	2:49 min
7	2:18 min	2:56 min
8	2:23 min	2:59 min
9	2:21 min	2:53 min
10	2:22 min	2:51 min

Both of them ended up with a final compressed size of 3.18GB and the new implementation was between 12 - 21% faster.

Here is another 3 runs also on level 1 & DEFLATE but with an uncompressed size of 10.6GB also artificially inflated in the same manner.

Run #	New Time (Commons Compress)	Old Time (Native Java)
1	7:04 min	8:20 min
2	7:24 min	8:25 min
3	7:18 min	8:14 min

Final compressed size was 9.42GB for both and it's now between 10 - 14% faster.
Overall this is a very small sample size and only tested on one machine so YMMW but I think that the change is warranted regardless.

2. Adds a config option to define a maximum size (in GB) for the backup folder rather than amount of backups. If the size exceeds the amount defined in config it will delete backups until under that size. This takes priority over the normal backup amount config and will be disabled by default.

3. Readds the option to not have backups with a custom name (through /backup start <name>) deleted, which I removed in Fix backups not getting deleted under certain circumstances #48, but with a less awful implementation this time. This is also disabled by default.

[Glease]

try reenable biased locking if you are not on java 8. the builtin java thing goes through the default deflater and uses synchronized. neither of these are free.

[Lyfts]

Just for note #112 is (hopefully) fixed, but I chose to do it in #101 as ThreadBackup is almost rewritten there and it would cause far too much conflict between the branches if done here.

[Ethryan]

Code looks good, my only thoughts are about @Glease comment from above. Otherwise this looks good.