STASHDEV-7788 Change `BasicOperationScheduler.responseThread` from a sin...

This is intended to alleviate the observed bottleneck where (according to `HealthMonitor` stats on one of our
production instances) `executor.q.response.size` and `operations.remote.size` keep growing under heavy load.
These response threads _do_ deal with objects that have locks (of the standard java.util.concurrent kind).  Having at least one thread per cpu core in the pool would ensure that work is spread out over the available cores and is never held up when there are idle cores.  The multiplier of 2 could be a safety factor in case thread affinity gets it wrong or could be an allowance for time spent waiting on locks. 

But I'm not really sure I'm qualified to answer your objections to the design of Hazelcast, these should really be directed to the Hazelcast folks on a different issue or PR.  The code is not very well not commented, and there may be other reasons for it being the way it is.  I'm averse to changing the design without fully understanding the thinking behind it. 

The alternatives for this PR:
1. mixing up calls to one of the executor services with the existing fixed thread pools, or
2. rewriting the existing fixed thread pools to use one of the executor services
seem less good to me, would be more risky, and less likely to be accepted by Hazelcast.