Update API docs and demos for recent worker improvements.

1. I have already listed several realistic scenarios, not just limited to a bad inflate/deflate implementations.
2. Users should call close. I don't want the maintenance burden of ensuring that Workers can be garbage-collected (and I reckon that this library was not designed to do that). **The use case that I showed (Worker pooling) requires that zip.js has a reference to the Worker.** This can only be implemented with refcounting, because GC will never collect the worker because zip.js retains a reference to it. And refcounting can only be done if there are explicit entry points (constructor) and exit points (`.close()`).

Worker pooling (sharing Workers among different instances of ZipReader/ZipWriter) is a desirable feature, **because the number of Web workers is limited**; currently the number of open zip files is limited to 20 because there can be at most 20 Web Workers (Firefox) on a given origin. Your desire to allow lazy/careless JS coders to rely on GC is incompatible with the worker pooling feature.
Please do not continue to argue for the preservation of the statement about GC, unless you propose a viable approach to implement worker pooling that does not require refcounting.