Update API docs and demos for recent worker improvements.

> This will happen only if you create more and more ZipReaders and don't release them. Why you want to do this?

Reading / writing multiple zip files sounds like a legitimate use case.

> But there is no reason to pretend that the GC won't work with zip.js (...) Just provide accurate informations and let users choose.

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. As you've noticed with `workerScriptsPath`, adding something to a public API means that you will commit to maintain the feature. Asserting that GC works and will continue to work correctly is a huge maintainability burden. I don't want to have this documented until the most relevant use case, worker pooling, is implemented. If it turns out that worker pooling can be implemented with a nice API while preserving GC, then you're free to submit an update to the documentation.

But now it is too early to assert that GC is and will be supported.