Adding inter-mod compatibility back into Oritech for NeoForge 26.1.2

[jshipley]

Description

I took a completely different (and much more conservative) approach to compatibility for 26.1.2 than I did for 1.21.1

Some of the main goals this time around:

• Accept / process items from AllTheOres and FTB Materials
• Add AllTheOres & FTB Materials to Ore Boulders and Resource Nodes if they're available
• When outputting items processed with Oritech machines, try to output vanilla items > Oritech items > ATO/FTB items
• Add some basic compatibility with other mods where supporting them specifically makes sense (such as being able to cast molten nickel to oritech:nickel_ingot if ATO and FTB Materials aren't available)
• Try to respect mod identities (much less processing/alloying of Oritech materials in other mods and other mods' materials in Oritech)
• Add some additional fun/useful interactions
• I did NOT add any new configuration options, or take any steps to make Oritech produce ATO / FTB Materials items instead of Oritech items. This might be a possible future improvement to make unification easier for pack creators.

This is a semi large change, so I'll try to summarize the main components:

• Added a new runCompatData task in build.gradle

  • added new compat sourceSet, dependency types (compatImplementation, compatCompileOnly, compatRuntimeOnly) that will add dependencies to compat without affecting the main build
  • compat code has access to Oritech code, but Oritech doesn't have access to compat code
  • src/compat/generated/resources will be included in Oritech build
  • Oritech data will be generated as part of the runCompatData task, but compat data will not be generated as part of a runData task

• Changed ResourceNodeFeature configuration (breaking change for any data packs that have customized this)

  • nodeOres and boulderOres block lists have become weighted block lists, with optional weight (default 1), required (default true), and requiresAny (default empty list) fields
  • "requiresAny" takes a list of block IDs, and the weighted block will be ignored if none of the listed blocks are registered
  • Technically, repeated list elements are OK but unnecessary. You can just have {"block": "minecraft:deepslate", "weight": 30} instead of repeating "minecraft:deepslate" 30 times.
  • Generic resource ores were added (basically recolored gold ore with a deepslate background) that will appear in bedrock below boulders that can have the deepslate version of those ores
  • AllTheOres and FTB Materials are configured by default now, and will generate in the ore boulders and resource nodes if those mods are loaded

• Recipe builders updated a little to allow for a "prefix" in recipe IDs

  • All existing datagen recipes were unaffected
  • Compat recipe IDs now all start with "compat/" (eg "compat/ae2/pulverizing/certus_dust" instead of "pulverizing/compat/ae2/certus_dust"

How Has This Been Tested?

• Feature has been tested ingame
• Optional additional testing details

For the world gen changes, I have tested with a combination of ATO and FTB Materials being loaded and unloaded. Their ores are included in the ore boulders when the mods are loaded, and not included if they're not loaded.

I've also reviewed the JSON files for the other recipes and made sure they looked good in JEI.

Checklist:

• My code uses the 'var' keyword where applicable.
• I have commented my code, particularly in hard-to-understand areas

Please let me know if there are any compat features that existed in 1.21.1 that I skipped that you would prefer to include in 26.1.2