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?

[spacebuilder2020]

Dimension ids can be changed, while provider names can't (or at least, they won't be under normal circumstances). It's just one less thing that we need to worry about, and as a bonus it's self-documenting.

That is true, though it was already doing that with the provider class instance. I did leave the old methods in for the ids but mostly because I didn't want to refactor the other mods at the time. With that said, and given the issues we had with using instance of, provider name is probably the best since an extended provider like RWG will probably not override the dimension name and an extended one like twilight will.

[RecursivePineapple]

I'll start saving profiles for every dimension (I've been profiling it, but I haven't been keeping them). In every dimension that I've profiled oregen time is basically zero.

The nether:

https://spark.lucko.me/m6S8EDfm1t

The worldgen call for the nether is all over the place so it's hard to get an accurate measurement, but it's still very small regardless.

[RecursivePineapple]

End asteroids:

https://spark.lucko.me/ODrz28E2Co

Some examples: