Support long-lived iteration

[ecton]

Originally I skipped building an iterator interface for scanning, but I realized there is no reason it can't be done. Ultimately the iterator is about the values produced, not about the other callbacks.

There are two possible ways to go about this: switch to storing the scanning state on a manually managed stack or by using a bounded channel interface.

The bounded channel interface may sound like a hack, but it has real merits: It keeps the file locked for read, preventing rename from unlinking the file contents during a compaction. This means that the iterator will be surprisingly resilient. The downside is that it will necessarily require a thread, meaning it would be a feature unavailable to no_std if we approached it that way.

The alternate requires opening the file for each step in the scan operation -- our FileManager layer will cache it, but that still is wasteful.