compatibility with new data format

To do:

- [ ] load "18-based interleaved" ("v2")

---

#6 added 1.13+ VoxelMap compatibility, which was also retrofit for Forge 1.12.

The current implementation has a work-in-progress for reading/writing "version 2" format, but has some bugs (looks weird when rendered with VoxelMap).
It could also be useful to be able to also read "version 1" and the old data in the "legacy" formats (up to 1.12.2 LiteLoader).

I've decided to name the known formats: legacy A, legacy B, v1, and v2.

The format of a tile zip can be inferred from the contained files:

- `key`: assigns numeric ids to the blocks present in a tile
- absent: legacy A
- "old" format: legacy B. `42 minecraft:jungle_leaves[distance=5,persistent=false]`
- "new" format: v1/v2. `42 Block{minecraft:jungle_leaves}[distance=5,persistent=false]`
- `control`: contains `version` entry
- absent: v1 or lower
- `version=2`: v2
- anything else: unexpected, not supported
- `data`
- 17x256x256 bytes: legacy A or B (always grouped byte order)
- 18x256x256 bytes: v1 or v2 (can't discern grouped vs interleaved byte order)

| | | | Legacy A | Legacy B | v1 | v2 |
|------------|----------------|---------|:--------:|:--------:|:--:|:--:|
| key absent | control absent | data 17 | x | | | |
| key old | control absent | data 17 | | x | | |
| key new | control absent | data 18 | | | x | |
| key new | control v=1 | data 18 | | | x | |
| key new | control v=2 | data 18 | | | | x |

legacy A:
- data: 17 based -> **convert data**
- key: absent -> **convert key** using The Flattening via global palette
- control: absent

legacy B:
- data: 17 based -> **convert data**
- key: old fmt -> **convert key** using The Flattening
- control: absent

v1:
- data: 18 based, grouped -> **convert data**
- key: new/old? -> probably always new; otherwise convert
- control: absent, or maybe 1

v2:
- data: 18 based, interleaved
- key: new
- control: version=2