Fix NeoForge data source cache keys

[mezz]

Problem

The cached binary-patch path (no-recompile path) could reuse patched Minecraft artifacts built from an older NeoForge userdev jar.

binaryPatch keyed the clean Minecraft jar, binpatcher tool, and textual args, but not the userdev-embedded patches.lzma data that binpatcher applies to the clean jar.

The same issue existed for access transformers: transformSources and applyDevTransforms recorded data source IDs, but not the userdev-backed data contents. Changing the NeoForge userdev jar must invalidate these cache keys even when Minecraft/NeoForm inputs and tool args are unchanged.

Observed Failure

NeoForge PR #3288 was released in NeoForge 26.2.0.10-beta. It changed the RenderArmEvent proxy parameters and updated ClientHooks.renderSpecificFirstPersonArm to the new eight-argument signature: neoforged/NeoForge#3288 (comment)

JEI then updated from NeoForge 26.2.0.6-beta, which still used the old five-argument signature, to 26.2.0.11-beta. CI reused cached binaryPatch and applyDevTransforms outputs while producing 26.2.0.11-beta artifacts. The client recipe sync test loaded minecraft-patched-26.2.0.11-beta.jar with neoforge-26.2.0.11-beta-universal.jar, then crashed because the patched Minecraft jar still invoked the old ClientHooks.renderSpecificFirstPersonArm method.

This first surfaced in JEI 26.2 build 63:
https://ci.blamejared.com/job/mezz/job/jei/job/26.2/63/consoleText

Fix

Add userdev-backed data source hashes to the NeoForge-specific cached binary-patch actions. binaryPatch now keys on the binary patch data source, and transformSources/applyDevTransforms key on the access-transformer data sources, matching the generic NeoForm data-placeholder behavior.

Tests

The regression tests model pairs of NeoForge userdev jars with the same NeoForm config, binpatcher command, sources jar, and universal jar while changing either embedded binary patch data or access-transformer data.

They assert that binaryPatch, transformSources, and applyDevTransforms cache keys change for their corresponding userdev data changes, and stay stable when the userdev contents are identical.

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

[Technici4n]

I'm surprised that this was not done before. I thought the data source system should already have handled this. 🤔

[mezz]

trying to do some git archareology to see some background on where the current state came from:

• Adds cache key contributions for referenced NeoForm data #89

  • added ExternalJavaToolAction.addDataDependencyHash
  • added PatchActionFactory cache-key hashing for {patches} data

• 7015e72 Add support for binary patches

  • createBinaryPatch did not add the patch data source to the action cache key

• Add results that allow using binary patched artifacts instead of running decompile/recompile #94

  • I think this moved these systems into the noRecomp path

• aa4f177 Apply NeoForge's ATs in the noRecomp pipeline

  • added ApplyDevTransformsAction.accessTransformersData which recorded only "access transformers data ids", not the contents

[mezz]

So for example, the addition here:

        ck.addStrings("access transformers data ids", accessTransformersData);
        ck.addPaths("additional access transformers", additionalAccessTransformers);

aa4f177#diff-862bc71488e496a3e6ffd97c9dd6909d7b96628deba9deea2ca8d83212c58a69R74-R75

these look like they'd do the same thing but only the addPaths one checks the contents of the ATs