Update API docs and demos for recent worker improvements.

>Reading / writing multiple zip files sounds like a legitimate use case.

Simply reading / writing multiple zip files won't make more and more workers, unless you don't release ZipReaders/Writers after you have finished with these files. If you must hold ZipReaders/Writers for a long time, just specify a even longer time in  `setInterval(zip.releaseSharedReaderWorker, time)`.

>At the moment, it happens that GC works as desired. I don't want to have GC documented, because there are no guarantees that this will always be the case in zip.js. 

I don't think browsers and the spec will remove this feature in future as it will break existing applications, and there is not reason to do it. Previously ZipReader.close() was a no-op, and the doc didn't warn what would happen if you didn't call close(), so chances are that some users already ignored it. That's why I was concerned that my patch on worker might break existing client codes in a subtle way, and now I'm glad that this won't happen. You view it as "a huge maintainability burden", but I think it is a good fool-proof feature, and the maintenance cost is low, because GC does the heavy work for us.