Handling of identical method signatures with different staticness while migrating

[sciwhiz12]

Currently, there is no marker for the static-ness of a method in the output files. This causes a slight issue when performing a migration across Minecraft versions of the mapping data, if a method retains the same method signature across both versions (usually, the intermediate mapping format in use assigns the same identifier) but changes in static-ness.
This causes the mapped parameter indexes to be off by one from the actual indexes (due to the implicit first parameter index being occupied in non-static methods), possibly causing validation errors and loss of that mapped parameter.

An example of this is https://github.com/ParchmentMC/Parchment/blob/96b967494dd830bb65a1ee18eeaf6ca6833d6585/data/net/minecraft/client/renderer/entity/EntityRenderDispatcher.mapping#L53-L57, specifically EntityRenderDispatcher#renderHitbox. This method was previously non-static in 1.16 but then became a static method in 1.17, which explains why the parameters, although correct, are off by one index.

[marchermans]

This is not supposed to be part of the export at all.
The exported data that compass generates should be mapping data and no metadata, which is completely by design.
If you need to know the static-ness of a method, then use the Blackstone data which contains this information pre-analyzed for you, and using mapping container merging, you can keep track of this accurately.