zipfs and write support

[Joel Uckelman]

I have what I believe is a functioning thread-safe read-write zipfs
implementation now---at least it passes all the tests I wrote---
subclassed from the existing zipfs classes. My question now is whether
it would be better to fold that code into the original read-only zipfs 
classes, or to keep the read-only and read-write versions separate.

One thing I don't know is whether there will be much of a performance
hit in using the read-write version for reading only. I implemented 
locking in the simplest possible way, with a ReadWriteLock, so it 
supports shared reads but exclusive writes. As a result, if you're
only reading, there should never be any lock contention, so I don't
expect this to cause much overhead. (The way which would permit for
greater concurrency, locking on subtrees instead of having one lock
for the whole ZIP archive, is a bit more work, so I held off on that
for now.)

Thoughts?

-- 
J.