Rework OverlayedFluidHandler to fix Fluid Parallel Limiting

[krossgg]

What

This PR reworks the OverlayedFluidHandler, which was naively copied from 1.12, to work with Modern's Fluid Storage systems. The reason is that Modern does not wrap all of a machine's fluid tanks into a single object used for recipe handling, unlike 1.12's IMultipleTankHandler/FluidTankList. Instead, we have separate instances of NotifiableFluidTanks (henceforth Noti Tank) attached to a machine that are stored in the capabilities proxy.

Previously, by wrapping all the Noti Tanks in a FluidHandlerList the allowSameFluidFill property of the Noti Tank was ignored, leading to instances where FluidRecipeCapability#limitParallel would not properly limit the parallel amount and return an incorrect parallel amount, usually skewed towards the higher end. Consequently, the recipe logic would be provided an incorrectly modified recipe and would not run, even if the same recipe as a lower parallel amount would work.

This issue has come about due to the reworking of Noti Tanks to actually respect allowSameFluidFill during recipe handling in #1975.

Here is an example of this issue:
I have a Large Electrolysis Chamber with its parallel hatch set to 64. It is electrolyzing Ammonium Formate (64B), which decomposes into 5B x H, 1B x N, and 2B x O.
My output space is a Quadruple EV Output Hatch, which has 4 tanks at 32B each. (There is plenty of output space for the item output)

Theoretically, the multiblock should be able to handle 6 recipes, as then the output slot for Hydrogen would cap out at 30/32B.
In actuality, the FluidRecipeCapability will calculate it to handle 12 recipes, as it thinks that the 4th slot can also be filled by Hydrogen.

This then gets passed back to the modifier, which will multiply the recipe by 12. However, when that modified recipe is matched against the multiblock, it fails, and no recipe is run.

Implementation Details

The new class has been called the OverlayedTankHandler, and the addFluidsToFluidHandler method (which was never used anywhere) has been deleted since it relied on the old OverlayedFluidHandler.
The nested class OverlayedTank now represents a single Noti Tank and will keep track of what fluids have been filled into it. It also remembers certain properties of the Noti Tank.

Additional Details

Note that NotifiableFluidTanks (or subclasses) are the only IRecipeHandler type that we use for fluid output in multiblocks. Assuming it stays that way (which it should), this solution should be robust enough for future features.

[Synthitic]

LGTM 👍

[screret]

Note that NotifiableFluidTanks (or subclasses) are the only IRecipeHandler type that we use for fluid output in multiblocks. Assuming it stays that way (which it should), this solution should be robust enough for future features.

someone might do something different,,,

[krossgg]

Ok well, we can let this be a bandaid until recipe handling is rewritten and I can separate the actual tank part from the recipehandler part, if we want. Right now they are completely coupled and will take significant effort to decouple.

[Spicierspace153]

lgtm!