Fix client lags when crafting from large stacks in stock keeper

[Frizi]

When using a stock keeper to issue a crafting order, the algorithm to calculate crafting ingredients tends to lag the client when working with large amount of items. After debugging it, it turns out that RecipeRequestHelper.resolveIngredientAmounts had a bug causing it to split the source stacks into individual stacks of 1 item each, while the same time having an O(n^2) complexity over the list of resolved ingredients of given type. During my testing attempting to craft while having 20K planks in the system causes the client to freeze for about 10 seconds. This happens when adding the crafting recipe for the first time, or when scrolling on the requested item in the stock keeper GUI.

Here's a proof of buggy behavior from the debugger session:

The fix changes how the item stacks are consolidated by comparing only the generic stack keys (which are also stacks), which prevents the list from growing and properly utilizes the stack amount value in resolved list. Now adding a crafting recipe or scrolling over one does not have any noticeable impact on client performance.

[zznty]

hello thank you for your time and contribution.
from my understanding, the recipe handler should consider each possible craft with required ingredient amount instead of full stack. this ensures that if lets say you have 7 birch planks and 1 oak planks in the system but want to craft 2 crafting tables, so it should consider 4 birch planks for first crafting operation then select oak planks as a valid fourth ingredient for the second operation.
that being said, it is selecting each item for each slot individually right now which is why the lag is created due to a lengthy list.
I haven't looked super close to the impact of your changes, so correct me if im wrong.
as an easier fix I was considering limiting maximum number of selected items to the size of package inventory since create puts hard limit of 9 stacks total per request