Non-matching lambda names (and more!) between userdev and prod

[lukebemish]

Minecraft Version: 1.20.2+

Steps to Reproduce:

1. Target certain fields/methods in non-neo-patched classes with mixins or reflection -- mainly, lambdas
2. Note that some of these methods/fields can have different names -- or worse still, different descriptors entirely -- between prod and dev. In the case of different names, this requires some digging to find the prod name as well as the dev name. In the case of differing descriptors, this can make targeting properly near impossible.

Description of issue:

For example, EntityRenderers#lambda$createEntityRenderers$2 in dev is EntityRenderers#lambda$createEntityRenderers$26 in prod, etc.

A complete count of such differences can be found at https://gist.github.com/lukebemish/0ea8618f20743b5867558fa54c13b65d (first file; the second involves a distinct parchment/JST bug), generated by https://github.com/lukebemish/EnvironmentChecker. Note that this also includes shifts in name of anonymous inner classes (those in FunctionCommand), various nest-escaping access$ methods, captured val$ fields, and of course lambda$ lambdas. Some are apparently not just renamed or descriptor-changed (due to generic wackiness), but are missing entirely on one side or the other.

To be clear, this is not a comparison of neo to vanilla! This is a comparison of prod and userdev neo, which are expected to match!

I was encouraged to open this issue here due to its scope. It affects MDG and NG, but is a bit broader than either and at least one potential fix lies in the scope of this repo.

In terms of potential fixes, a summary of things I have seen presented on discord or elsewhere:

• "Fix" the recompiled jar in userdev to have the proper names. I attempted this; given descriptor shifts and missing methods, I have concluded that it is infeasible.
• Include some comment on lambdas in userdev with their prod name, placed their by the decompiler. This is plausible to implement, but does not solve the actual issue -- namely, descriptor shifts are still a serious concern, as are anonymous class shifts, and it violates the fundamental assumption that a mod that runs in prod, ought to run in userdev.
• Use solely binpatches in userdev and remove the recomp step entirely. This is feasible -- in fact I have implemented the relevant bits to handle, say, line numbers with this approach -- but I have been told it is not a desired solution.
• Distribute full binpatches. In my opinion, this is by far the best short-term solution. This would involve including binpatches in the installer for all classes in MC, not just those neo modifies. Post Shrink binpatches by remapping constant pool indices InstallerTools#7, this should in theory not have as outsized of an impact on installer size as it may have before -- it's also a solution that is trivial to implement (just remove the filtering in https://github.com/neoforged/NeoForge/blob/1.21.x/buildSrc/src/main/java/net/neoforged/neodev/GenerateBinaryPatches.java#L56-L58 that currently filters to only those used in sources).