Refactor RecipeModifier and OC system

[krossgg]

What

This PR aims to more clearly define how the RecipeModifier system is meant to function.
One key element of this is that recipes should not be mutated by a Recipe Modifier.
Instead, each recipe modifier should describe how the recipe should be changed given the current state of the recipe and machine. This replaces the old system of OCParams and OCResult, which, to be frank, was confusing and often led to inconsistencies due to modifications being overwritten by recipe modifiers.
The scope of OCParams and OCResult have been narrowed to simply be used for OverclockingLogic.

Modifier Details

A new functional interface ModifierFunction has been introduced which will take a GTRecipe as an input to its apply method and return a modified copy of the recipe. The original recipe should not be mutated. The ModifierFunction is allowed to return null if the recipe should be cancelled.

The RecipeModifier functional interface now only takes the current state of MetaMachine, GTRecipe and returns a ModifierFunction describing how the recipe modifier thinks the recipe should be changed. Again, the original recipe should not be mutated. The returned function should not be null; if a modifier wishes to cancel a recipe, it should instead return a modifier function that nulls the recipe. This can be done via a lambda or the static ModifierFunction.NULL. The identity can also be referenced using the static ModifierFunction.IDENTITY.
All existing recipe modifiers have been updated to match these desired behaviors.

For convenience, the ModifierFunction class includes the nested FunctionBuilder class, accessible via ModifierFunction#builder, which provides a variety of parameters to build the function of your choosing with ContentModifiers.
ModifierFunctions can also be composed or chained via the compose or andThen methods.

The RecipeModifierList class still exists as a way to collect and apply multiple recipe modifiers. It no longer has any special behavior and instead simply composes its list of modifiers. It keeps track of a running recipe so that each consecutive modifier is being calculated in order based on what would be applied by previous modifiers.

The RecipeModifier#nullWrongType method is a utility method that simply returns ModifierFunction.NULL while logging the incorrect use of a recipe modifier.

Parallel and Overclocking Logic Changes

The parallel methods no longer do anything to a recipe. Instead, they simply calculate and return the amount of parallels that can be achieved with the given parameters. It is up to the caller to use this number as they wish.

The OverclockingLogic class has had its structure changed to that of the previously nested interface Logic, as there is no need for outer class definition. The functional interface, assisted by a helper factory method create taking the place of the constructor, is sufficient. Default interface methods are now used instead of static helper methods.
The Overclocking methods have been modified to account for the maximum parallels that a recipe can be run at. This fixes rare cases where, if already previously modified, a recipe may parallel overclock too much and would be unable to run due to missing inputs or output space.

Additional Details

The Large Turbine Machine modifier has been changed. Like other generators, large turbines will now parallelize a recipe (via fastParallel) until they produce their desired power. Then, the efficiency stat of the rotor holder will multiply the burntime of the fuel.

Outcome

Happi life

[screret]

this is SO MUCH BETTER than what we had tysm