Fix bulk compression not detecting configurable comb chains in Productive Bees

[Forever-178]

Fix #218

Now when attempting to get a chain, it first tries an exact match. If the exact match fails but a fuzzy match succeeds, it will try to dynamically generate a chain by calling the overridden recipe.assemble() to determine the upstream and downstream outputs.

[62832]

Sorry for the delay in getting back to this issue, I've been a bit too radio silent still for a good while.

The logic looks fairly sound for this PR, but I am quite concerned about the multiple static fields you've introduced now to hold all the recipes in, and the resulting impact this might have on performance and memory footprint. I will have to give this another look to see if it can be condensed a bit.

[Forever-178]

Sorry, I didn't fully consider the performance implications when writing this part of the code.

I have re-evaluated this section of code. I believe the memory consumption caused by the static fields used to store recipes will not be very large, because the newly added static fields such as compressionRecipes only hold references to the recipes held by RecipeManager. The actual memory overhead is just the List itself.

The part that is more likely to cause significant memory consumption should be the dynamically generated compressChain. For the same item, under extreme circumstances, there may be a large number of variants that are similar but differ in NBT, and each variant itself may contain a large amount of irrelevant NBT. These are more likely to occupy a substantial amount of memory.

Additionally, as the number of dynamically generated chains increases, the initial query for a certain item may become slower. Moreover, I have not handled the destruction of dynamic chains here, which may cause the chains to expand further.

The existing data structures of chain and chainCache are designed for pre-generated chains and may not be suitable for the dynamic chain scenario here.