ISPN-4651 LevelDB crashes JVM when stop() is called concurrently with write()

https://issues.jboss.org/browse/ISPN-4651
There are some perf results (with JDK5 and 6 only) here:
http://www.javaspecialists.eu/archive/Issue165.html

@rvansa I wouldn't expect users to clear their caches all the time either, but I wouldn't want a user to get a live-lock the very first time they try it in production. The Semaphore javadoc explicitly allows live-locks: "This class also provides convenience methods to acquire and release multiple permits at a time. Beware of the increased risk of indefinite postponement when these methods are used without fairness set true."

@wburns `drainPermits` may help with stop/clear starvation, but I don't like the idea of a busy loop waiting for disk operations to finish. I would rather use an explicit volatile boolean + lock to block new write requests until the clear finished (in addition to the semaphore). 

If we figure out how to handle the writer starvation issue, we should definitely put this in a separate class in core. Most of the time we use `ReentrantReadWriteLock` in core we don't really need the reentrancy, but it's the only alternative we have. So there are probably a lot of places where we could use a slightly faster `NonReentrantReadWriteLock`.