Re-running the data generator in the same folder causes previously generated -reports and- .snbt files to be deleted

This bug was introduced in 1.13-pre2, and does not affect prior versions.

Reports being deleted were fixed in 18w50a, but SNBT files are still deleted.

The data generator's caching logic deletes any files that it did not generate. However, this is implemented by checking for a list of files that existed in the output folder at startup, and then deleting any files that were not recorded as being generated. The NBT to SNBT data generator (but not the SNBT -> NBT one), along with all the reports (Block List, Item List, Command Syntax), do not record their hash upon generation. Since the data generator only gets a list of files to delete at startup, they will still persist initially; they will only be deleted on the second run. The end result is that the reports only show up every other time.

To Reproduce

1. Create a folder named input, and copy a level.dat file from some world into there. Rename the level.dat file to level.nbt

2. In the parent folder to that folder, run java -cp minecraft_server.1.13-pre2.jar net.minecraft.data.Main --all --input input/.

3. Look in the newly-created generated folder. level.snbt, reports/blocks.json, reports/items.json, and reports/commands.json should all exist.

4. Run java -cp minecraft_server.1.13-pre2.jar net.minecraft.data.Main --all --input input/ again.

5. The rest of the generated files will still exist, but level.snbt, reports/blocks.json, reports/items.json, and reports/commands.json will all be missing.

When using a debug log4j config, additionally note that the first run will give [main/DEBUG]: Caching: cache hits: 0, created: 1165 removed: 0 while the next run will give [main/DEBUG] Caching: cache hits: 1165, created: 0 removed: 4; subsequent runs toggle between Caching: cache hits: 1165, created: 0 removed: 0 and that. The files themselves are not recorded in .cache/cache.

Fix

I'm not entirely sure what the purpose of this cache even is; perhaps it could be written in a less-janky way as a fix... but I'm not sure how to best do that while still serving its purpose.

This can be fixed by adding code to record the hash in CommandsReport, BlockListReport, and ItemListReport (done in 18w50a along with the changes to the reports in general); in addition the same code present in SNBTToNBTConverter can be copied into NBTToSNBTConverter (or perhaps they should be rewritten into one abstract class since the majority of the logic is the same for both).