STASHDEV-7788 Monitor a few extra statistics in the `HealthMonitor` logging

Monitor a few extra statistics in the `HealthMonitor` logging:

 * `lock.count` which is the number of in-flight lock operations
 * `executor.q.response.stats` consisting of:
    - number of responses processed since last log
    - cumulative deserialisation time (nanosec resolution) since last log
    - the single worst packet in terms of deserialisation time since last log

The intention is to find out why the `responseThread` is getting stuck.
Deserialisation should be super quick, right?
Each deserialisation is a few microseconds, but even light load can easily generate thousands of them.  A number in the 0 to 99 range (when monitoring every few seconds) would probably be nothing to worry about.  But something about 100 or more would be interesting and worthy of investigation.  100 ms is a lot of nanoseconds, and would be easy to miss.  But with the decimal point, it's obvious and easy to search for. 

I deliberately do the division in `ResponsePacketHandler.getResponseStats` (which will be called every few seconds) instead of `ResponsePacketHandler.handle` (which could be called thousands of times a second).  I didn't expect anyone else would be as concerned about division performance as me in the year 2014 :-).