Refactor typescript table iterators

[coolreader18]

Description of Changes

A few main goals here:

• have our iterator functions return an Iterator object so that users can use its combinators like filter() and find() and reduce(). It's a very new JS api but we happen to know that the module code will always be run in an environment that has it* :)

• improve lifecycle handling for iterator handles - mainly, if an iterator is not run to completion, it will now eventually get garbage collected, whereas before we would have a resource leak.

It turns out that the easiest way to do both of those things was to turn TableIterator into a generator function, which also happens to make the code much easier to read. Hooray :)

* I did mention it in table_cache (which isn't run in our module host) but it's fine, since that's only in the type system and IteratorObject is defined in typescript's lib.es2015.iterable.d.ts but is only given fancy methods in lib.esnext.iterator.d.ts - so if the user uses esnext, they'll have access to them, but otherwise not.

Expected complexity level and risk

1: this better separates concerns and makes the code clearer in its purpose.

Testing

• Refactor, so automated testing is sufficient.

[cloutiertyler]

This only makes typing changes on the SDK side and we control the server side environment, so I'm cool with this. I also met with Noa to discuss.