Fix distributed deadlock between two sessions

This code gets rid of holding a lock during the call to Send(). In general, it is a good idea not to hold locks while making potentially blocking operations.

I've seen the other pull request, which removes the lock when reading responder_ in HasResponder.

I think that is not correct solution: the responder_ member is a mutable property in Session, and as such needs some kind of synchronization for access. There is no real argument that this would work more than observing the fact that it doesn't seem to cause problems.

Another problem is that the Disconnect() method is also protected by the same monitor, and this patch makes sure that calls to Disconnect also succeed without having to wait for a long Send() to return.

At last, this is what the code in quickfixj does.
Yes, you are right -- the "fix" doesn't really help at all. I'd say I agree that the simple solution right now might be to do what was proposed in the other pull request.  My solution just does not work... (It needs a sender thread, which we can argue about having or not, but in the meantime we should probably have the solution that does not end up sending messages out of order.)

That being said I'm all for a solution where threading is handled outside of QuickFix, or at least a solution where that is a possibility.