Performance degradation when INPUT from inventory that has occupied slots that can't be extracted from

[MasonD]

Slots that return ItemStack.EMPTY upon simulated extraction because they're a machine's input-only slots should return isDone() = true because there's nothing to extract, but since we're using getStackInSlot() in peekExtractPotential here, such slots report extract-able items and never become Done.

Since LimitedInputSlot doesn't actually keep a running total of all possible items that could be extracted, I think we can safely change this back to the commented-out type.extract(handler, slot, Long.MAX_VALUE, true) line just below. LimitedInputSlot clears extractSimulateCache to null upon the actual extract operation, so we only need peekExtractPotential predict how many items could be extracted from the next single extract instance.

peekExtractPotential is used:

• in moveTo to limit the number of items SFM tries to move between two slots, but if the inventory is reporting only a 64 in a simulated extract it should by all rights only allow us to extract 64 when it comes time to do the move anyway.
• in SFMASTUtils.getInputStatementForSlot and a couple other places used to generate example extracts from inventories for the various ways of inspecting that. I think we should refactor all these a little bit so that more of the logic lies inside SFMASTUtils, which we would have check both getStackInSlot and a simulated extract directly using the ResourceType before deciding if it should return an INPUT or OUTPUT statement. If it has items but returns EMPTY upon simulated extract, SFM giving an example OUTPUT statement would be more helpful to the player than the current INPUT one.

[MasonD]

I've already done some small refactoring of the code generation to support OUTPUT statements for UnofficialBackport 1.12.2, seen here for the PackagedAuto JEI recipe transfer code generation integration I wrote, so some of the work for that is done