improve lua intepreter thread locality

(Enhancement, not sure what's the impact of it, but I suspect it is significant for use-cases with single shard lua invocations)

Currently, an interpreter is acquired on the coordinator thread see `ServerState::BorrowInterpreter()`

But for single shard lua transactions we could actually use the interpreter running on the destination shard.
see `Service::EvalInternal` and `if (CanRunSingleShardMulti(sid, *params, *tx)) {` check.

We can not not do it now because of several reasons:
1. the tx fiber should not block on anything as it will immediately create huge latency for all the operations scheduled on it.
2. racing with other coordinator threads could lead to deadlocks where the tx A with lower id was blocked on the transaction B with higher id that acquired the interpreter but could not run because it waits for A to finish.

I believe the problem is that semaphore functionality of limiting number of interpreters is coupled with actually getting the interpreter. If we separate this and keep the limits at the coordinator level, we could get interpreters at shard level if needed

Idea: separate interpreter acquisition from the semaphore limits and use:
` global vector used_interpreter_count(pool->size())`

1. semaphores will still be enforced at the coordinator level.
2. Coordinator will proceed only if used_interpreter_count is less than a limit.
3. Once it proceeds it can acquire unconditionally an interpreter object in the thread it runs. So in case of `CanRunSingleShardMulti`, it will take it from the shard thread.

Start with ServerState::BorrowInterpreter(), Service::EvalInternal, and the CanRunSingleShardMulti check to trace interpreter acquisition and coordinator limits. The work is done when single-shard Lua transactions can use the destination-shard interpreter while coordinator-level limits remain enforced without introducing fiber blocking or transaction deadlocks.

Written by the indexing model from the issue text.