YT-28453: Drop per-action closure allocation in two-level fair-share thread pool

Every `Invoke` wrapped the user callback in a freshly heap-allocated
`BIND(&TBucket::RunCallback, ...)` closure, solely to install the target bucket as
the current invoker around execution -- a malloc/free plus a refcounted wrapper
construct/destroy on the hot path of every scheduled action.

The plain `TThreadPool` avoids this: it stores the callback as-is and installs its
invoker via `SetCurrentInvoker()` in the execute path. This does the same -- the
bucket is already kept alive in `TAction::BucketHolder`, so `DoOnExecute` installs
it as the current invoker right before returning the callback, and `OnExecute`
resets it before fetching the next one (mirroring `TSchedulerThread::EndExecute`).

### Why

Profiling the `BusXferFS` threads of an RPC proxy showed ~10% of their CPU in the
fair-share scheduling machinery, with a per-action allocation visible in `Invoke`.
This removes that allocation.

### Benchmark

Adds `yt/yt/core/benchmarks/fair_share_thread_pool.cpp` (there was none for this
pool): open-loop (Invoke cost), closed-loop (bounded in-flight, true end-to-end
scheduling rate), and round-trip latency.

Measured on a quiet host (node-pinned, medians):

| Config | Before | After | Δ |
|---|---|---|---|
| open-loop, 1 producer | 410-434 ns/op | 301-336 ns/op | -23..-27% |
| closed-loop, pool=1 | 760-864 k/s | 954-968 k/s | +12..+25% |

Contended multi-thread configs are coordination-bound (combiner lock + futex
wakeups) and unchanged; the win is on the CPU-saturated per-action path, which is
what the bus xfer pool hits.
commit_hash:c2ec77121bf52d0058042a0c9358a8de7620b69d

0 files changed, 0 insertions, 0 deletions