Trade Logic Fixes

[cubefury]

Supersedes #37.

Fixes #36.
Fixes GTNewHorizons/GT-New-Horizons-Modpack#22713.

Changes:

1. Added oredict compat for consumable & non-consumable items
2. Fixed a bug where allowing oredict would cause a trade to accept any item durability
3. Removed unnecessary item stack copying for item type matching

Developer Comments:

1. This oredict support implementation is abit overkill for our needs (we only have the crop stick trade which needs oredict support for 1 logWood) but allows us to add new trades in the future where oredict support would be needed.
2. Oredict-enabled items will try to extract an exact match first, before pulling alternatives from oredict matches.
3. I checked to ensure that items which could be viewed but not extracted from an AE2 subnet don't count towards satisfying a trade requirement.
4. I made a best effort to check this would not break existing trades + non-consumable inputs + NBT behaviour (eg. minotaur axe trade for spawn egg).

Full disclosure:
Technically, a bug can occur if a trade requires multiple inputs which can be satisfied with a single item. eg. if a trade wanted 1 oredict:logWood + 1 Oak log. Since the required items are checked separately, having 1 oak log in the input slots would satisfy both these conditions. However, when the trade is actually performed, it would void the oak log and fail the trade. This bug does not affect the pack currently as we do not have trades that fit this condition.

I'm not sure if there's an elegant solution to address this, especially if we look at the general case of checking whether a set of items with overlapping oredicts can be mix-and-matched to fulfill an arbitrary set of oredict/non-oredict requirements (intuitively it sounds like a np-complete problem). We can possibly deal with the voiding issue by tracking what items were consumed and returning them to the output slot if the trade fails while trying to pull the required items.

Tested in SP+MP daily 214.

[UltraProdigy]

Only saw one functional problem... as far as the bug maybe you could make a local mutabe copy of the inputSlotCache and decrement it as each requirement “reserves” items during the check so it can't double count?