Ore dictionary cleanup

[danyadev]

Summary

OreDictionary handling has accumulated a lot of lifecycle logic, special cases and outdated hacks inside GTProxy. This PR separates the different responsibilities and simplifies the registration flow

Changed recycling recipes

Details

Name	Before	After
UIV energy distributor
Booster Tier 1/2/3&4 gives: Meteoric Iron/Ledox/Mythryl Previously it always gave Meteoric Iron
Enchanting Table Ender Chest and other forge hammer recycling recipes

About Forge Hammer recycling changes, for example Enchanting Table and Ender Chest: previously, the code was looking for the first material component which is a non-metal crystal, but once found, added the main item material, provided it just has a dust form. Now it provides the first non-metal crystal dust instead, that's why we're getting diamond dust, ender eye dust, and so on, instead of, say, obsidian dust.

Unify OreDict prefix parsing

Some OrePrefixies methods did not handle mismatches when resolving a prefix, leading to inconsistency and some potential bugs

Extract and decompose OreDict registration

The large GTProxy.registerOre() method was moved into a dedicated OreDictRegistrationHandler class and split into smaller pieces for validation, aliases, special registrations, material handling and recipe processing

Improve blacklisting

Previously, GTOreDictUnificator blacklisting had two parts:

1. sNoUnificationList list, which was managed by addToBlacklist() and isBlacklisted()
2. ItemData.mBlackListed, which was mainly set on get() methods when useBlackList is true, isBlacklisted() is true and GregTechAPI.sUnificationEntriesRegistered is false

So the blacklisted state was only picked up if get() happened to be called before a certain point during pack loading and with useBlackList=true. This was inherently unreliable: a stack could be blacklisted too late, or its unified form could simply be requested too late for mBlackListed to ever be updated

Now, blacklist state lives only in two sets: one for exact ItemStack entries and one for wildcard-blacklisted items. The blacklist is managed exclusively through addToBlacklist() and isBlacklisted(), and mBlackListed is entirely gone

Make OreDict unification incremental

The old implementation replayed the entire OreDict events list during registerUnificationEntries() twice: on Init and on PostInit in order to:

1. reset all the cached unified stacks in ItemData (mUnificationTarget)
2. register associations (in sItemStack2DataMap)
3. mark stacks blacklisted (technically resolved in a previous change)
4. apply an override for the unified stack (in sName2StackMap)
5. do GTRecipe.reInit() to apply the new unified stacks in the recipes where the previous unified stack was used (initially unified stack is the first stack we got from a oreDictEvents HashSet, which has undetermined order...)

The new flow is truly incremental:

1. On oredict entry registration:
   1.1. register an association
   1.2. if an oredict is a specified override, make its stack unified and reset cached unified stacks for across its oredict
2. On PostInit: do GTRecipe.reInit() once to update recipes created before the unified stack was overridden

In result, the associations and the correct unified stacks are available right after the oredicts are registered, not only after two Init and PostInit checkpoints

I chose the beginning of PostInit because all of the unified stack overrides happened by the end of Init. Postponing the GTRecipe.reInit() any longer would only result in slower reInit because the number of recipes is increasing constantly. I also added a warning log in case something goes wrong in another mod or when adding a new override

Separate aliases

A large chunk of spaghetti code turned out to be aliasing. Created a new OreDictAliases class with direct and clear alias mappings

Remove dead code

A lot of checks were merely impossible to pass because the handler rejects an oredict via one of the earlier checks

The large ignore lists were cleaned up by simulating their registration and checking how the handler responds to each of them

Performance

There's a minor improvement due to regexp removal and only one GTRecipe.reInit() pass instead of two:

• OreDict event handling allocation dropped from roughly 132 MiB to 92 MiB.
• Recipe re-unification dropped from roughly 200 MiB / 139 ms to 149 MiB / 94 ms.

What is left

OrePrefixies and GTOreDictUnificator could use some cleaning up too

Checklist

• I have tested this PR in DevEnv
• I have tested this PR in Fullpack
• This PR is in compliance with the GTNH AI Policy
• This PR requires another PR in order to merge: better unification blacklist check kuba6000/Mobs-Info#147, remove duplicated ardite & manyullyn saw blades NewHorizonsCoreMod#1958

[Guvante]

Everything I checked seemed fine but still some parts I didn't get to (OreDictRegistrationHandler has some functions I haven't checked, and more importantly auditing GTProxy removals to ensure they seem covered by the new code)

The structure seems decent and is mostly of a form that would allow transitioning to an extendable model (I don't think it necessarily needs to move out of tree but allowing customizations without recompiling the project would be pretty cool)