Add selective voiding and ME hatch capabillity to Distillation Tower multiblocks

[krossgg]

What

This PR creates custom Machine and RecipeLogic classes for DistillationTower multiblocks, like the Distillation Tower and the Large Fractionating Distillery. In doing so, the ability to omit output hatches on selected layers and void the contents of those layers has been added. In addition, this allows for ME Output Hatches to be used as part of the structure while still providing exactly one output per layer.

Implementation Details

This functionality is achieved by creating a list of fluid handlers when the structure is formed. The output hatches are iterated from top to bottom and added to this list. In any omitted layers, a VoidFluidHandler is added instead, which will void any fluid given to it.

Throughout the recipe logic, instead of going through the recipe's own matching/handling system, the distillation tower will match/handle its own fluid outputs via the DistillationTowerLogic#applyFluidOutputs method.

This does not break the ability for the LFD to run regular distillery recipes, even if the first layer happens to not have an output hatch. The machine will keep track of its first non-void fluid handler and output to that instead.

Once a recipe is able to be run and the inputs are consumed, the recipe logic will update and expose a trimmed version of the recipe running to any output displays, such as Jade or the machine UI.

Outcome

Resolves #2103
Players are now able to omit layers to void those layers' outputs or use ME Output Hatches to deal with mass fluid in a layer.

Additional Information

This new class is friendly to custom multiblocks (as long as they are oriented vertically), with an optional parameter specifying the height offset between the controller and the first fluid output layer.
New shapeinfos for all sizes of DTs and LFDs have been added in order to properly represent how they should be built.
A new recipe type UI has also been designed for the DT recipes

[mikerooni]

Unfortunately can't review the actual recipe logic yet, but I have some small (optional) recommendations ^^

[screret]

this probably shouldn't be hardcoded like this? or is there no other way

[mikerooni]

Might be able to merge this together with the interface I suggested for the parallel limit

[krossgg]

Needs to be hard coded in order to use DTs output matching method.

GTRecipeType#searchRecipe , which is used in the default recipe logic searchRecipe, is hardcoded to use GTrecipe#matchRecipe. This does not work for me because it would not respect the separation of layers.

In a future PR, I plan to extract out this repeated hardcoded matching condition from various places in RecipeLogic so that it becomes easier to write custom recipe logic without copy pasting a lot of methods with only a single line change (like you see here with the DT logic). However that is beyond the scope of this PR.