[WIP] [RFC] first class inline iterators: iter it = myiter() to allow perfect forwarding of iterators, with delayed evaluation

[timotheecour]

iterator myiter(seed:int):auto=
  for a in 0..<seed:
    yield a

# not allowed, since can currently only be used in a `for` context
# let it = myiter(5)

# proposal:
iter it = myiter(5) # not a concrete type: can't use `var a: type(it)`

doAssert it is iterator int
doAssert type(it).name == "iterator int" # with import typetraits

# we can consume it directly
for i in it(): echo i # prints 0, 1, ..., 4

# or we can build a pipeline:
# we can use lazy functionals (eg `mapLazy`) that take input (inline) iterators and output (inline) iterators
iter it3 = it.mapLazy(a=>a*10)

# we can inspect the intermediate types:
doAssert it3.type == iterator int

iter it4 = it3.filterLazy(a=>a<25)

# finally we consume it4
for i in it4(): echo i # prints 0, 10, 20
# this would produce exactly same code as if we did the fully inlined version (that can't use UFCS)
for i in filterLazy(mapLazy(myiter(5), a*10), a<25): echo i

# we can also consume the iterator via a proc that takes input iter and output concrete type (eg seq[int])
let x = it4.toSeq

This solves a number of problems with iterators, especially inline iterators which currently aren't 1st class citizens.
This would enable to pass them around as iterator T to other procs that accept iterator T (which is currently impossible for inline iterators).
It would make for nicer error messages, easier debugging, easier to write iterator pipelines.
This would be a zero-cost abstraction (compared to fully inlining the code)

fixes these

• fixes this: Exporting a toSeq overload messes up iterator visibility Exporting a toSeq overload messes up iterator visibility RFCs#512
  because toSeq could be written to take iterator T

[timotheecour]

might be obsoleted by #11992