Fix ores being unscannable in spawn chunks, and incorrect cache-rebuilding logic.

[C0bra5]

This PR fixes 2 bugs with visual prospecting:

• A long-standing issue (at least 2.1.0) where, in some cases, chunks within the spawn chunk radius cannot be prospected by players.
• VP will sometimes fail to identify ore veins when re-scanning a world after a player deletes/resets the server-side cache file, usually by nuking the visualprospecting folder entirely, as it tends to solve a lot of issues.

Spawn Chunk Bug

This occurred due to an intermittent race condition:

The ServerCache object registers itself as an FML event handler in its constructor. Sometimes, the ServerCache.instance property is only accessed (and therefore instantiated) well after GT dispatches its VeinGenerateEvent events during world creation. Causing VP to miss all the events during world creation.

The solution to this issue is simple: Ensure that the instance is registered before the world creation process begins.

Since this late instantiation issue also occurs with the ClientCache object, I also took the liberty of ensuring that it's created well before world creation is ever triggered.

This race condition seems very inconsistent in the current stable release (2.8.4), but can reliably be reproduced in experimental 80 using the following steps:

1. Ensure the game is closed.
2. Delete any save files you have.
3. Delete the journeymap, TCNodeTracker, and visualprospecting folders in your .minecraft folder.
4. Launch the game
5. Set your render distance to 6 to ensure it's smaller than the spawn chunk radius, and that no extra chunks are generated.
6. Create a new survival world with cheats enabled and a randomized name and seed (to prevent any collision that could cause some sort of early loading)
7. When you load into the world, open journey map and ensure ores are displayed
8. /gamemode 1
9. Give yourself a prospector scanner, the 5x5 radius one with NULL material.
10. /gamemode 0
11. Right-click the air to scan nearby ores.
12. The ores will appear in the scanner, but the ores won't be added to journey map because the ores were never added to VP's cache when the world was loaded.

You can confirm that the bug is happening/the fix is working by attaching an IDE to the full pack (experimental 80 is recommended), setting a breakpoint in the ServerCache constructor, and on line 325 of GTWorldgenerator (where the VeinGenerateEvent event is dispatched) and following the previous instructions. The breakpoint in GTWorldgenerator should trigger well before the one in the constructor of ServerCache when the bug occurs.

For this PR to work in experimental 80, you will need to apply it as a patch to the current dev branch, since it already uses a pre-release version of VP.

This PR should address the root cause of the following issues:

• Visual Prospecting can't add ores to the map around spawn GT-New-Horizons-Modpack#10273
• Visual Prospecting Breaking When Ore Vein Detected near spawn GT-New-Horizons-Modpack#10547

Existing worlds where this issue is present will either need to run the /vp_recachespawn command, update their config to enable the recacheVeins or delete their Visual Prospecting folder entirely to force a proper re-scan of the world.

Cache Rebuild Bug

This bug occurred because VP was performing an incorrect subset check. It was asking if the ores found in an ore chunk were a subset of a vein type, instead of asking if the ores in a vein type were a subset of the ores found in an ore-chunk.

To reproduce this bug, and confirm that the bug is working you can follow these steps:

1. Create a new creative world with the following seed: -1624882341703909143
2. /tp -122 100 -24
3. Dig down until you find the redstone vein
   • You can break a block and discover it to ensure the spawn chunk fix is functioning correctly.
4. Once you find the vein, save and quit
5. In your .minecraft folder, delete the visualprospecting folder
6. Load up the world
7. Break an ore from the redstone vein
8. If the bug is active, the vein will not be logged; if this PR was applied, the vein will be recognized.

javaw_qbE9AeVWsl.mp4

Known Edge Case Failings

There is still an edge case in which VP fails to detect a vein while analyzing the world to rebuild its cache:

When a vein generates in such a way that one or many of its ore types do not generate (Eg, generating close to the surface or bottom of the world, cutting off the layers that contain one of its core components) VP will not be able to properly match the vein as well it cannot determine a viable match for the vein.

The following vein is a good example of this edge case, as 2/4 of it's ores types just won't be ge generated becuase they would have generated in dirt or air:

We could probably put in some extra work to identify these ores, since we can do some "layer analysis," but honestly, I'm not sure how I would properly implement it. I know roughly how GT veins are laid out, but considering this is a fallback system that only ever gets triggered when things go catastrophically bad, I'm not sure it's worth the time investment.

GT5u needs a fix

There is a further bug where GT5u will tell VP that it has generated and placed a vein at a given location, even though it hasn't (usually because the vein was generated in the air or in blocks that cannot be replaced with ores). This needs to be addressed directly in GT5u. As the saying goes: garbage in, garbage out.