Chore: new Delegate blueprint iterator implementation

[MotionlessTrain]

Closes # Closes # Closes #

Changes proposed in this pull request:

• Adds a new AbstractDelegateBlueprintIterator class, which can be used to create new BlueprintIterators based on other iterators, to e.g. apply extra logic to incrementing and decrementing, whilst not being dependent on a particular iterator type
• The logic in AbstractBlueprintIterator has been separated in an interface (which is implemented in the delegate iterator as well), a new abstract class (to share the iterator with skip condition logic), and the actual implementation The latter has been renamed into a new class AbstractStructureIterator, whose name has been inspired by the StructureIterators "registry" class. That is now the base class of the different iterator types
• This will be used by a rework of the quarrier in Minecolonies, which will use an approach with a "LayerBlueprintIterator", which iterates over a single Y-level and then finishes, using a delegate iterator which defines the actual iteration pattern for that layer

Review please

[MotionlessTrain]

This is binary breaking, do we want that or not

Whoops, something I have not considered at all. If that is not okay, would renaming AbstractStructureIterator back to AbstractBlueprintIterator and moving the result enum back into that class solve it? Or would it be more involved?

[Raycoms]

This is binary breaking, do we want that or not

Whoops, something I have not considered at all. If that is not okay, would renaming AbstractStructureIterator back to AbstractBlueprintIterator and moving the result enum back into that class solve it? Or would it be more involved?

I'm not 100% sure. You can test it out by trying to load minecolonies with it and having a builder build sth

[someaddons]

btw small thing but I'd rename from delegate -> wrapper, since thats how other things are named aswell e.g. InventoryWrappers etc

[MotionlessTrain]

Yeah, for simplicity of things undoing the class split might be easier :D then you can do iface + delegate from iface which should be fine

I had the class split to make sure that the increment and decrement with skip condition code would be the same in both classes. I guess I just copy it over to AbstractDelegateBlueprintIterator with a todo that both functions could be extracted to a base class.

I first thought about using the delegate/wrapper there too, but that would mean I would need to duplicate the logic on minecolonies' side, where I would be implementing it. Extending the original base class to use for the delegate seemed to be impractical too

[MotionlessTrain]

Things found during binary compatibility test:

1. NoClassDefFoundError, due to Result being moved to the interface
2. Changed method signature:

   com.ldtteam.structurize.placement.AbstractBlueprintIterator com.ldtteam.structurize.placement.StructurePlacer.getIterator()

   This particular one is nasty, as I need to support returning delegate iterators too. I may need to extend AbstractBlueprintIterator by the delegate/wrapper (and ignore all of its fields) after all, to solve it.

Interestingly, those were the only two things I found. I simply changed StructurePlacer to store an AbstractBlueprintIterator (my version) instead of an IBlueprintIterator, and it somehow was enough for the builders, miner and quarrier to continue

To better be safe than sorry (no clue which other mods would be affected), I'm going to revert the split from AbstractBlueprintIterator into IBlueprintIterator, AbstractBlueprintIterator and AbstractStructureIterator, and inherit AbstractDelegateIterator from AbstractBlueprintIterator instead (and rename it to AbstractBlueprintIteratorWrapper, or something like that. Name is not set in stone yet). It will just ignore the base class' fields, and override the methods to use the wrapped iterator's methods instead

[MotionlessTrain]

This seems sufficient now for the use case in Minecolonies