Update API docs and demos for recent worker improvements.

> Still better than refcounting, because even if a single .close() call is missed for any reason, the worker is doomed to persist with the page.

Not better neither worse. With refcounting, one worker is left behind as well.

> > Resource leaks.
> 
> A timer consums very little resource. JS code of zip.js itself would consume resources, and it persists with the page.

I'm not referring to the timer, but to the worker (where resource = worker quota and memory). When the user forgets to clear the timer, then a new worker will be created while the old one is still alive.

---

It seems to me that you're viewing GC as the silver bullet to memory problems; this is simply not true. If the user accidentally retains a reference to the ZipReader object, then the associated worker will not be GC'd. By documenting that Workers will be GC'd if close() is not called, the lazy/careless library user might not call `.close()`, because it is documented. It is overly optimistic to expect that JS developers think about memory and understand how GC works, so it's better to be on the safe side and NOT document that Workers may be GC'd.