Properly handle situations where only mappings metadata is available

[zml2008]

this can occur if the remapping classpath is incomplete

@TheCurle, this should resolve the issue you were having. Could you confirm?

Looking into this area more for this fix, there are a few more open questions about parameter remapping:

• How do we handle mappings formats that don't contain static information -- is the memory impact of explicitly adding a true/false static key to every method mapping worth it?
• I have had a request from a user to be able to provide parameter/LVT mappings from old name to new name, not by index as is common. What is a sensible way to do that? Probably both inheritance/bytecode models and mappings models would need slight changes, to track the original names from bytecode, but supporting both index-based and name-based is a touch awkward.

[LexManos]

Our main goal is minecraft, which in most cases uses the same name for every entry. Combined with the fact that is IS valid to have duplicate names. Having it based on index and potentially bytecode offset would be the way to go. So I'm not really seeing a reason to have name based LVT remapping.

As for the need for static info. Technically we could set that behind a higher flag and require mappings to explicitly define 'this's variable. However the current system will have the bytecode data to tell.if its static. So I dont see any case where it wont exist.

[marchermans]

I need this merged for FGNext,
I got it nearly working entirely with custom dependency and am working on a legacy module where this fix is needed, because not all dependencies are known.

[LexManos]

Any chance you can put a CL flag on it? Exploding when inheritance cant be computed is important. But I can see why people would want a 'best effort'. So having a way to opt-in to a warning instead of an error is the way we need to go.