The use case is as follows: let's say I have a scheduler that uses
libfringe for context switching. A single thread may open several
sockets, each of which presents a std::io::Read interface, and
waiting in Read::read requires having a reference to the yielder
inside the socket.
This could be worked around with RefCell in the API consumer, but
there is no real reason to not implement it in libfringe.
close#48
This makes more sense, because "generate" implies *running*
a generator, not *returning* from a generator. That name was
a vestige of the time when libfringe only really provided a .next()
implementation, which made marginally more sense together with
.generate(), but it doesn't anymore when we have .resume().