Fabric Data Fixer API (v1)

[Treetrain1]

This is a copy of #3644 with changes to use a single schema tree across mods to remove isolation issues across datafixers.
After testing, I believe this is the key to the schema registration isolation issue because the base schema is now the last schema of the last registered data fixer, except for the first registration of course because the parent will just be the vanilla data fixer.

Possible concerns:

• Mods could break the data fixers of other mods by creating a custom schema that cancels the registration of block entities or entities. This would theoretically only affect the mods that have registered a data fixer before the problematic mod.
• Mods could just not register their block entities and entities, limiting the effectiveness of data fixers.

Todo:

• Write testmod implementation for the "isolation" issue
• Fix existing testmod's biome fixes for 1.19.3+

[Treetrain1]

The only major concern I have left is that since the schemas are in a single parent line, any mod could cancel the registration of block entities and entities within the schemas by not calling super.registerBlockEntities or super.registerEntities in a schema.
Correct me if I am wrong, but wouldn’t this break all of the parent data fixers?

[Treetrain1]

Also, I’m wondering what the best way to get modders to register their block entities and entities to the schema would be. Perhaps an integration into the Fabric docs website wherever it talks about block entities and entities and an announcement somewhere.
In any case, if this is merged, I think modders should get notified in some way about this.

[Treetrain1]

Question.
The vanilla block entity and entity builders have a String id parameter that is used to find an instance of the id in the schemas.
Fabric basically ignores this with its builders and builds anyway, so I’m wondering if this should be implemented alongside this PR.

This is already included in this PR (though likely controversial since it logs an error), but I’m wondering what any of your thoughts are on this.

[lukebemish]

I believe this still has the exact same schema/fixer ordering transitiveness issues it did way back last time I took a poke at it on discord? (Namely, issues with mutual transitiveness between different mods as fixers to fix transitive entries are only applied the one time) At any rate, no changes have been made that would resolve those issues.

[lukebemish]

To elaborate: mod A and B add an item and a BE each, which they want to fix. Mod A adds both to a schema and adds a fixer for each afterwards. Mod B does the same. DFU only runs fixers during the specific update step when that fixer exists -- so if mod A's stuff is before mod B's schemas are registered, then a mod A item in a mod B BE will not be properly fixed. A slew of similar cases pop up when you consider that "transitive" fixing is accomplished through the AddChoiceType stuff and can in fact be removed if that format no longer exists -- so transitivity in the same mod, with some other mod in the middle, can also cause issues.