Add loot modifiers

[Juuxel]

Still WIP, I'd like more feedback on the feature and its design and the format before finishing the details.

• Adds a data pack API to do simple loot table modifications such as adding new pools. The format is similar to the normal loot table JSON format.

  Example loot modifier file

  This loot modifier adds a pool to builtin green wool loot tables dropping a poisonous potato, and sets the count of all result stacks to 10.

  {
    "target": {
      "type": "fabric:require_all",
      "children": [
        {
          "type": "fabric:loot_table_id",
          "loot_tables": ["minecraft:blocks/green_wool"]
        },
        {
          "type": "fabric:source",
          "sources": "any_builtin"
        }
      ]
    },
    "pools": [
      {
        "rolls": 1,
        "entries": [
          {
            "type": "minecraft:item",
            "name": "minecraft:poisonous_potato"
          }
        ],
        "conditions": [
          {
            "condition": "minecraft:survives_explosion"
          }
        ]
      }
    ],
    "functions": [
      {
        "function": "minecraft:set_count",
        "count": 10
      }
    ]
  }

• Cleans up the loot table event mixin (it was processing all loot-related registries...), and moves most of the code out of the mixin

Why?

Loot tables themselves are data pack files, so it makes sense to allow modifying them using more data pack files without having to resort to overriding loot tables or adding code. Modifiers can also be overridden in data packs.

Loot modifiers are intended to be an alternative - possibly the recommended alternative where possible - to LootTableEvents.MODIFY. There won't be any features that can't be done through Java code in mods.

NeoForge has a similar feature called global loot modifiers which is much more complex. As far as I can tell, Fabric API already supports their functionality in the LootTableEvents.MODIFY_DROPS event, and I don't think we need data pack support for complex use cases. The loot modifier format can be extended later with new features if desired.

TODOs and open questions

• Resolve code todos
• Add more test cases
• Support load conditions for loot table modifications Automatically works due to the use of SimpleJsonResourceReloadListener.scanDirectory
• Should there be an always false modifier target?
• Should modifiers be able to modify pools (FabricLootTableBuilder.modifyPools)?
  • If so, how would they target a pool? Can we improve the code API too when it comes to this?
• What should the name of the feature be? The initial name was "loot table modifiers" but "loot table modifier target" was quite a mouthful.