Refactor ore and worldgen

[RecursivePineapple]

Summary:

• Unify the ore worldgen system (moved all GT vein generation to GT, moved asteroid gen to galacticgreg)
• Moved gt++ and bartworks veins into Oremixes
• Removed all ore tiles
• Changed ore blocks to use the standard GT ISBRH
• Fix the weird bartworks vein info in NEI (removed the bartworks NEI ore page entirely)
• Improve vein discoverability in NEI (find recipes for oreproc items will show veins)
• Clean up detrav scanner code & stop it from blocking the server thread
• Optimize asteroid generation & make them look better
• Add ice asteroids (nitrogen, ammonia, oxygen, etc)
• Add new ore stone types for galaxyspace planets

Todo:

• Test the random code that I touched
• Make a PR for the byte -> int meta change

Changes:

• Remove GT and BW TileEntities for ores
• Make new interface for placing, mining, and inspecting ores (OreManager) to unify all three systems (can be removed after the material system is added if we want)
• Unify the ore vein config into OreMixes
• Remove the various ore gein generators and unify them into the GT one
• Refactor the GT ore vein gen (the logic shouldn't be changed at all for GT veins, GT++ and BW have slight changes due to moving the random calls around)
• Remove the GT++ and BW ore ISBRHs and use the existing GT renderer (via a new interface, IBlockWithTextures)
• Improve the NEI orevein integration
• Refactor void miner code a bit
• Refactor detrav scanner & prevent it from freezing server (scan is now async via coroutine/generator)
• Improve GT asteroids & GT end asteroids (I made sure to chunkify and optimize the worldgen, it's basically instant)
• Move end asteroid generator to galacticgreg and move space orevein gen to GT to unify them
• Clean up some galacticgreg code (I tried to avoid touching code as much as possible, but I had to largely rewrite the asteroid generator)
• Changed dimension matching to operate on dimension names instead of the chunk provider name
• Added ice asteroids to asteroid dimensions (same 'ore' as IRL - oxygen, hydrogen, methane, ammonia, co2, sulfur dioxide, etc - see OreMixes for full list)
• Added stone system to make it easier to add new stone types for ores
• Refactor some GT machine & tool code to accept int metadata instead of byte metadata
• Add temporary IMaterial interface to allow the ore system to accept any material that implements it (will be removed when the new material system is done)
• Remove ore packets since they aren't needed anymore
• Optimize the GT++ worldgen a bit
• Add co-operative scheduler that lets you run expensive tasks on the main thread without blocking it (asynchronously)
• Added a way to query worldgen ore layers, instead of doing it manually each time
• Add an Everglades dimension block
• Rename the GT++ raw ore oredict from oreRaw to rawOre (which is what it should've been)
• Optimize drilling plants (halved the time taken from ~120k ns to ~60k ns)

[spacebuilder2020]

Changing to use dimension name will probably break FE's multiworld since you can name a dimension. This would effectively defeat the purpose of not using hardcoded dims since you would not be able to create a multiworld with GT ores in it again...
https://github.com/ForgeEssentials/ForgeEssentials/blob/1.7.10/develop/src/main/java/com/forgeessentials/multiworld/MultiworldManager.java#L281

[RecursivePineapple]

@spacebuilder2020 I've never used forge essentials, but it looks like it'll be fine as long as the multiworld uses the proper provider. It determines what ores to generate based on the provider's dimension name, so if you make a multiworld with the nether provider it'll generate everything normally.

https://github.com/ForgeEssentials/ForgeEssentials/blob/1.7.10/develop/src/main/java/com/forgeessentials/multiworld/MultiworldManager.java#L243

[spacebuilder2020]

ok, I thought it was based on the world name. If it is the provider dim name then it is probably fine, but I want to know what your reasoning for changing it to the name?

[RecursivePineapple]

End asteroids:

https://spark.lucko.me/ODrz28E2Co

Some examples:

[boubou19]

this must not be merged until VP is made compatible again

[YannickMG]

Just to make sure, does this require a sister PR of some sort for dreamcraft or any other mod which has compat for GT ores?

[RecursivePineapple]

@YannickMG There are a few outstanding problems, but they're just a matter of moving a few lines over to the new API. They'll still crash the game though. I'm working on VP currently.

https://github.com/GTNewHorizons/Draconic-Evolution/blob/2835b7a54eb902dd274e25de7f2a4a994a1f77dd/src/main/java/com/brandon3055/draconicevolution/integration/ModHelper.java#L113
https://github.com/GTNewHorizons/BloodMagic/blob/84e41cc920379717d9466bb60509e7aa27c01cfd/src/main/java/WayofTime/alchemicalWizardry/common/summoning/meteor/MeteorParadigm.java#L207

Plus the handful of references to sBlockOres1.

[YannickMG]

This is an amazing improvement that the pack codebase sorely needs if we want to keep being able to evolve the pack. Due to the size of this PR (each bullet point in your PR description could have been it's own PR) I cannot meaningfully review every change to the logic, but thankfully this system is critical enough that we should find any hidden issue soon enough.

What I can do is review changes to existing APIs as well as review the usability and readability of new APIs. I also pointed changes that seemed odd, inconsistent or confusing.

I hope to help ensure new APIs are as usable as possible and make our codebase as clear and maintainable as can be so that if/when a bug is found in the code that was added, it is as simple as possible to resolve it.

Comments have been addressed

[Caedis]

Can you add EFR's deepslate as another stone type for OW ores?

[YannickMG]

If we're doing that I think I also saw the ore generate in tuff? Not sure if it should.