Feature/method signature intersection

[LlamaLad7]

Overhauls InvalidInjectorMethodSignatureInspection and related infrastructure. Apologies for this not being broken up into digestible commits, there were simply too many interleaved changes.

I appreciate that this will be tricky to review, the complex logic is documented where I felt it was needed and lots of new tests are provided.

The general changes are

• Injectors are now split into those that work with instructions and those that don't (@WrapMethod)
• Injectors now usually declare their expected signatures in one of several structured formats, rather than the group system as before
• Suggested method signatures are computed by intersecting the expected signatures from every target instruction/method. This is made possible by the structured formats, with separate intersection logic for each required format that makes use of format-specific knowledge. Attempts are made to produce signatures that are most useful, for example by avoiding @Coerce where possible and prioritising the most specific supertype when it is not possible. Additionally, ModifyVariable and ModifyArg suggestions prioritise the handler's existing return type where available.
• In the special case where the handler's existing parameters are valid for every target but the return type is not, an attempt is made to suggest a new return type without requiring parameter changes. The logic here is very complex since it works for any type of expected signature. Nonetheless it has good complexities, and will always produce a result if one exists, though this result may not be globally optimal (whatever that even means).
• Several bugfixes to related injector logic, including incorrect Coerce handling, ModifyConstant not supporting .class literals, Inject allowing captured locals without the target method's parameters, WrapMethod not requiring exact staticness
• The mixin parameter name inspection is reworked to be more sensible. For example if 2 signatures contribute a name each for a parameter, we shouldn't expect the parameter to match either of those names, because it represents them both and will likely be named as such