Update API docs and demos for recent worker improvements.

>Guaranteed correctness of GC imposes some restrictions on how we can develop zip.js, e.g. worker pooling.

Yes, but I think this restriction is reasonable. Previous versions of zip.js didn't leak even if close() is not called, so I don't think it is a good idea to regress in a future version. If a pooling implementation has to leak if close() is not called, re-think about it. If JS gains WeakReference in future (now there are WeakMap and WeakSet, so I think I'm not not daydreaming), it will be a perfect way to hold the pooled worker(s).

Take a look at the examples in old zip.js docs:

http://gildas-lormeau.github.io/zip.js/core-api.html#full-example

```
function unzipBlob(blob, callback) {
  // use a zip.BlobReader object to read zipped data stored into blob variable
  zip.createReader(new zip.BlobReader(blob), function(zipReader) {
    // get entries from the zip file
    zipReader.getEntries(function(entries) {
      // get data from the first file
      entries[0].getData(new zip.BlobWriter("text/plain"), function(data) {
        // close the reader and calls callback function with uncompressed data as parameter
        zipReader.close();
        callback(data);
      });
    });
  }, onerror);
}

function onerror(message) {
  console.error(message);
}
```
The problem is, zipReader.close() is only called if the reading have succeeded, what if getEntries() or getData() failed? Simply adding zipReader.close() in onerror() also doesn't work well.

In [this demo](http://gildas-lormeau.github.io/zip.js/demos/demo2.html) there is no .close() at all.

Additionally, in the [FS API](http://gildas-lormeau.github.io/zip.js/fs-api.html), there is even no close() method!

So how can we expect users make all possible .close() calls when zip.js itself ignores them here and there?