IterAdapter improvements

[Ichthyostega]

IterAdapter needs some more love....
Especially, the iteration control API seems misaligned.

• maybe we should better define the extension point through a free function (to be picked up by ADL)
• alternatively, we could shape the conrol API similar to Java's Iterator interface, i.e. hasNext() and next()

But before we can do any of these changes, we need more experiences with the use of the whole concept

[Ichthyostega]

due to the work on #353 (which was caused by the use within the QueryResolver), I need to change the iteration control API to free functions right away.

[Ichthyostega]

build quite some iterators meanwhile, but didn't settle down on a solution here... thus keeping this one open for now

[Ichthyostega]

now seems to be more mature, rather just requiring a bit of renaming and cleanup. Anyway, keeping this open but pushing to future -- still needing more practical experience with those iter adapters and itertools

[Ichthyostega]

meanwhile the problem is rather that we've gotten several families of iterator-implementations, each of which has its own implementation style and iteration control API. Most of them seem to settle on three free functions as extension points, and especially the API for IterStateWrapper turns out to be convenient and easy to implement. However, IterAdapter and the IterSource (virtual) interface got away with just two extension points. IterAdapter turned out to be very versatile -- but also hard to implement correct. Typically you'd have to read and understand the code in IterAdapter itself each and every time, which is unacceptable. An iteration control API should be clear and obvious enough to be just coded up at usage site

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin

[Ichthyostega]

During the last weeks, I did quite some clean-up and improvement work related to our iterator framework. It seems clear that usage converges towards some common ground

• most everyday usage relies on IterExplorer, the pipeline builder, which is quite mature meanwhile
• when specific processing is required, the State Core concept is the preferable way for implementation; it can be adapted easily to expose a Lumiera Forward Iterator
• on some rare yet relevant occasions, we need an completely abstracted or opaque iterator; this is when the IterSource framework is used.

Largely, the situation is satisfactory — yet the design could be improved: The internal interface expected by IterSource is designed clumsily and hard to understand and get right. It would be much more adequate to swap that out in favour of the State Core interface, which expects three functions, and these could be virtual functions in that case. On that occasion, also the very first implementation, the IterAdaptor should be replaced with a delegation to a State Core ⟹ #1125

However, another usage pattern is not addressed satisfactory yet: this is when we need to package an iterator as opaque value — similar to what was specified as »piggyback iterator« many years ago. In a contemporary programming framework, this would translate to the specification of a single iteration function that can then be packaged as an inline opaque functor ⟹ #130

[Ichthyostega]

Attach to parent #1420 (Framework for Iteration and Lazy Processing).