Fix validation for item and fluid tags

[Mqrius]

What

When you use an incorrect item tag in a KubeJS recipe input for GT machines, the error you get is very non-descriptive:
Error in 'ServerEvents.recipes': Index 0 out of bounds for length 0

For incorrect fluid tags it's even worse, the recipe just gets registered without errors but the fluid input will require 20mB of nothing.

A broken item tag here can also mean a valid item tag that has no items registered in it.

This PR fixes checks for tags as inputs.

Implementation Details

The problem with the item tags is that the validation checks if (stack == null || stack.isEmpty()), however a tag Ingredient always has one TagValue in values, so isEmpty() is always false.

It's solved by checking the number of items in the item tag and throwing a descriptive error when it's zero.

The problem with fluid tags is similar, but there's an additional issue. Tags aren't actually bound to their items/fluids yet in minecraft's registries during this phase of the recipe loading. KubeJS gets around this by mixing in on getItems (IngredientTagValueMixin.kjs$getItems) and resolving the binding itself in TagContext.patchIngredientTags.

Since GTCEu owns Fluid Ingredients, we can just patch it in without a mixin. Needs a little indirection to handle the case where KubeJS is not present though.

With that, fluid tags are checked the same way as items.

Outcome

Incorrect item and fluid tags are caught and reported clearly.

Additional Info

Example broken recipes:

event.recipes.gtceu.assembler('tfg:assembler/test_item_tag')
    .itemInputs('#broken:tag')
    .itemOutputs('minecraft:dirt')
    .duration(100)
    .EUt(GTValues.VA[GTValues.ULV])
	
event.recipes.gtceu.assembler('tfg:assembler/test_fluid_tag')
    .inputFluids("#broken:tag 20")
    .itemOutputs('minecraft:dirt')
    .duration(100)
    .EUt(GTValues.VA[GTValues.ULV])

Potential compatibility issues

I haven't tested this without KubeJS, but this indirection guard is used in other places in the repo without issue.

Tested against 7.5.2 on 1.20.1 but presumably this applies to 8.0.0 too.