[bugfix] remove possible deadlock in XQueryPool

I have not found a ticket for this deadlock, but it has bitten me quite often during development against eXist-2.1. Unfortunately, I could not reproduce it in a unit test. I often triggered a deadlock when saving a file into the database using oXygen (not sure what protocol the eXist-plugin of oXygen uses) and immediately refreshing a HTML page created by the eXist application oXygen was saving into.

The symptoms were as follows: 
most of the threads were stuck in borrowCompiledXquery, waiting for a thread that in turn waited in openCollection, executing ReentrantReadWriteLock.acquire. The ReentrantReadWriteLock was of course held by one of the borrowCompiledXquery threads.

The deadlock detection in ReentrantReadWriteLock.acquire failed to detect this state.

I think to avoid this situation, the borrow-type methods generally should not acquire locks in synchronized code.

My patch removes the problem - I have worked with a patched eXist-2.1 since April and never had any issues. It looks a bit suspicous that synchronization on "this" is used twice in the borrowObject()-method, but the only thing that is happening in the second synchronized block is a call to remove(key), and my assessment of that method is that this should be safe in this context. 

You cannot trust the Travis build for eXist as at present it is not running the test suite (because our test suite takes too long for travis). Instead it only compiles the code