Fix ClassCastException with create 6.0.8.1.

[Acuadragon100]

In fabric-create version 6.0.8.1 (see Fabricators-of-Create/Create@64b6788) they added explicit porting-lib FluidType objects which replace the ones normally fetched by porting-lib's getFluidType function. Only problem is that Kilt replaces this function with one returning the forge FluidType, so you get a ClassCastException. The easiest way I know to reproduce the issue is to install Immersive Engineering, since that causes a crash when loading a world.

This pull request resolves this by simply wrapping each FluidType in the AllFluids class in with the Forge FluidType.

It should be noted that this replaces the fluid types built into create. Let me know if you think I should handle everything in the getTypeOf instead (to keep the normal create fluid types in the constants as-is), or if I should keep it but add a fallback just in case some create addon decide to add their own fluids with a mixin into getTypeOf.

The crash when loading Kilt with Immersive Enegineering and Fabric Create 6.0.8.1:

java.lang.ClassCastException: class io.github.fabricators_of_create.porting_lib.fluids.FluidType cannot be cast to class net.minecraftforge.fluids.FluidType (io.github.fabricators_of_create.porting_lib.fluids.FluidType and net.minecraftforge.fluids.FluidType are in unnamed module of loader 'knot' @1b604f19)
	at knot//net.minecraft.class_3611.getFluidType(class_3611.java)
	at knot//net.minecraftforge.fluids.FluidUtil.getFilledBucket(FluidUtil.java:677)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
	at knot//blusunrize.immersiveengineering.common.crafting.fluidaware.IngredientFluidStack.method_8105(IngredientFluidStack.java:65)
	at knot//blusunrize.immersiveengineering.common.crafting.ArcRecyclingCalculator$RecipeIterator.getRecycleCalculation(ArcRecyclingCalculator.java:206)
	at knot//blusunrize.immersiveengineering.common.crafting.ArcRecyclingCalculator$RecipeIterator.process(ArcRecyclingCalculator.java:173)
	at knot//blusunrize.immersiveengineering.common.crafting.ArcRecyclingCalculator.run(ArcRecyclingCalculator.java:68)
	at knot//blusunrize.immersiveengineering.common.crafting.ArcRecyclingCalculator$1.fillInRecipes(ArcRecyclingCalculator.java:134)
	at knot//blusunrize.immersiveengineering.common.crafting.ArcRecyclingCalculator$1.onServerStarted(ArcRecyclingCalculator.java:112)
	at blusunrize.immersiveengineering.common.crafting.__ArcRecyclingCalculator_1_onServerStarted_ServerStartedEvent.invoke(.dynamic)
	at knot//net.minecraftforge.eventbus.ASMEventHandler.invoke(ASMEventHandler.java:48)
	at knot//net.minecraftforge.eventbus.EventBus.post(EventBus.java:302)
	at knot//net.minecraftforge.eventbus.EventBus.post(EventBus.java:288)
	at knot//net.minecraftforge.server.ServerLifecycleHooks.handleServerStarted(ServerLifecycleHooks.java:106)
	at knot//xyz.bluspring.kilt.Kilt.registerFabricEvents$lambda$10(Kilt.kt:132)
	at knot//net.fabricmc.fabric.api.event.lifecycle.v1.ServerLifecycleEvents.lambda$static$2(ServerLifecycleEvents.java:49)
	at knot//net.minecraft.server.MinecraftServer.handler$zmp000$fabric-lifecycle-events-v1$afterSetupServer(MinecraftServer.java:3842)
	at knot//net.minecraft.server.MinecraftServer.method_29741(MinecraftServer.java:650)
	at knot//net.minecraft.server.MinecraftServer.method_29739(MinecraftServer.java:265)
	at java.base/java.lang.Thread.run(Thread.java:833)

[BluSpring]

I'm not a big fan of having to do this, to be honest with you. But I don't really see another way around this.

Brickmaster1 and I were trying to figure something else out with the fluid system since it's very screwed, especially when mixing Create Fabric + Registrate Fabric + GTCeu, do you think you could take a look at what's been done there and trying to make sure it actually works? It's absolute hell of a codebase.
https://github.com/Brickmaster1/Kilt/tree/version/1.20.1

[Acuadragon100]

Well, I had a look.

Looks like the biggest issue is that create-fabric only likes to inject into one getFluidType method, which is essentially whichever one it finds first, even if create fabric is recompiled to explicitly target the getFluidType-call returning the porting lib FluidType. Also, I'm not sure if it's possible to make it target the method properly via remapping when it's wrapped with a proxy method because when I tried it I got an error about an invalid method name. The easiest way I could get it working was to set the priority of the entire FluidInject-mixin to 1001 so it would always inject last, and just not touch the porting lib method in that mixin.

[Acuadragon100]

All right, think I have a working setup now for both Create 0.5 and Create 6.
Did a field test with some mods I happened to have laying around as well (so I can confirm it does indeed solve the Immersive Engineering crash this pull request addresses).

As for the getFluidState-function, it should behave the same way as it did before, but porting lib is now injected first.

I briefly looked into the GregTech mod as well, and it unfortunately does not launch, but it also uses its own custom FluidBuilder.

Should I pull request it over on Brickmaster1's repository?

Either way, here's a link to it: https://github.com/Acuadragon100/Kilt/tree/registrate-fluids

[BluSpring]

I'd say PR it over to Brick's yeah