Granulate tests

[supersaiyansubtlety]

Closes #25

Merging will be a little awkward.
I'll need to update this PR for any tests added by PRs merged before it, and any current PRs merged after it will need to update their tests.

New PRs that add tests should be based on this one.

• gives each proposer its own test class and input source set + obf jar
• makes it easier to trace things back to their un-obfuscated names through constant names, variable names, and comments
• adds a CommonDescriptors class used throughout proposer tests
• reworks the MethodEntry factory so that it combines return and param descriptors rather than taking a whole method descriptor
• eliminates some jank I started in the conflict test

[OroArmor]

before reviewing, this is very needed. im excited

[OroArmor]

I think that every test should be boxed from the others. picking and choosing classes, especially with wildcards just kicks the can further down the road. I think this could be done either with source sets (best option, but idk if you can do something like testInputs/conflict or something. I think the more realistic option is to have com/example/<test-package> and make each of those its own jar. While this would probably lead to duplication among the test classes, i dont think that is that big of a deal, and it means changing one suite doesnt indirectly affect others.

[OroArmor]

Not sure how i feel about this. its not bad, but it feels a bit weird in the actual tests.

[supersaiyansubtlety]

Can you elaborate?
Is the issue just with CommonDescriptors, or with the way it's used with the reworked methodOf method?

[OroArmor]

imo seeing D or J just feels slightly off. I like the concept but one character values are usually weird and I think im just picking up on that. I'm mostly curious on what others think.

[supersaiyansubtlety]

@ix0rai thoughts on this?

[ix0rai]

i like this the way it is, anyone interacting with this code should be familiar enough with bytecode to know the descriptors by heart

[supersaiyansubtlety]

I think that every test should be boxed from the others. picking and choosing classes, especially with wildcards just kicks the can further down the road. I think this could be done either with source sets (best option, but idk if you can do something like testInputs/conflict or something. I think the more realistic option is to have com/example/<test-package> and make each of those its own jar. While this would probably lead to duplication among the test classes, i dont think that is that big of a deal, and it means changing one suite doesnt indirectly affect others.

I wanted to minimize changes to actual tests for this PR; if we're ok with copy-pasting (maybe renaming) test input classes, I can make it so there's no overlap (it might make testEnimgma more confusing though because it'll have duplicate obfuscated classes).

Note that "DELEGATE_PARAMETERS" is the only obf-jar that currently uses a custom combination of tests classes.

[supersaiyansubtlety]

OK, individual test input source sets are working and CONTRIBUTING.md has been added (please critique).

One slightly annoying thing about the separate source sets is testEnigma needs its own simple_type_field_names, but imo it's worth it.

[ix0rai]

i love this. i have Opinions about camel case for folder names but it brings a tear to my eye how beautifully segmented the tests are. great work!