Split really large methods

[cretz]

Yay, another fun algorithm. Currently on the JVM a method size cannot exceed 65535 bytes. Otherwise, with ASM at least, you get the dreaded Method code too large!. Some other JVM languages don't implement code splitting because it's too rare/complex, but we probably need to. At least one generic impl is here (see specifically this package and these tests) but I think I can do better.

I need to decide whether I want to split at the WASM level or the JVM level. Probably the former since we have an insn reworking step that counts stack depth anyways. Either way, I figure while the method is too large, we'll just walk the insns finding a large enough section to pull out. Then pull it out to a synthetic method w/ the params as the stack and the result set if needed. The rules for a section to find is probably where many stack values come down to one/zero, no locals are accessed, and all contained within a block.

While this might not be good enough for generic JVM uses, it should be good enough for me.

[cretz]

There's some kind of bug that still exists here that is not setting the stack properly. Still working...

[cretz]

Ok, I think I need to change tack here. Currently this runs a de-dupe algorithm which can also reduce overall size among other things. However, it is quite complicated.

To solve this specific problem, I need to just find the largest non-jumping section of code I can (but still within some % of overall size), save off the stack and locals, call the fn, restore the stack and locals and go from there.

[cretz]

I created a new algorithm to do this: https://github.com/cretz/msplit. I plan on embedding that code in here, using CodeSizeEvaluator to determine when it's needed, and call it in a loop until the methods come down to size.

[cretz]

Decided to just react to MethodTooLargeException instead of using the code size evaluator. Will run some more tests before closing this..