Update API docs and demos for recent worker improvements.

>Not better neither worse. With refcounting, one worker is left behind as well.

If a user missed 1% calls to .close(), one worker is left with probability 100%; If a user missed 1% calls to releaseSharedReaderWorker(), one worker is left with probability ~1%. That's the difference.

>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.

The old worker will be GC'd when all old ZipReaders using it have been GC'd, so it won't live for a long time. Clearing timer doesn't help anything.

>If the user accidentally retains a reference to the ZipReader object, then the associated worker will not be GC'd.

So it seems the user is not careful or skillful enough - then how can he/she deal with the more messy refcouting system? GC is not the silver bullet to memory problem - yes, but refcounting has been proven to be worse.