perf(thread): trim semaphore signal-side contention (min-wait fast path + signaler combining)

[Coldwings]

Summary

Two independent optimizations to photon::semaphore that cut the signal-side
spinlock convoy seen when several vCPUs signal one semaphore -- the shape a
WorkPool produces. Based directly on main; does not depend on #1650.

Changes

• Skip the resume path when the count cannot satisfy any waiter (m_min_wait):
  signal() keeps a lower bound of what any waiter needs (or -1 when nobody
  waits), adds its count and returns immediately while the total stays below that
  bound, without taking splock or walking the queue. wait_interruptible()
  gets a matching lock-free fast path. The two sides form a Dekker pair, both
  sequentially consistent, so at least one observes the other and no wake-up is
  lost:

  signal(): m_count.fetch_add(n)     then load(m_min_wait)
  wait():   m_min_wait.store(count)  then load(m_count)
  

• Let one signaler at a time walk the resume path (combining): once
  m_min_wait keeps the hopeless signals out, the ones that remain all pile onto
  splock and the same queue, redundantly -- whoever is in the resume path
  re-reads m_count and covers the others' counts. A signaler now claims the
  path with a RESUMING bit and serves everyone; one that finds it taken sets
  RECHECK and leaves. The holder does not release until it has read m_count
  with RECHECK observed clear, and the release itself reports the bit back in
  case someone set it at the last moment. Every transition is a read-modify-write
  on m_resume_state, totally ordered with the fetch_add on m_count.

• Adds thread/test/perf_semaphore.cpp, a benchmark (NO_REGISTER).

Motivation

With several vCPUs signalling one semaphore, signal() used to take splock and
walk the wait queue on every single call, even when the count in hand could
satisfy nobody, dragging in the waiters' thread structs -- hot lines of other
vCPUs. That spinlock is where the time goes.

Measured with thread/test/perf_semaphore.cpp, 8 signalling vCPUs x 50k ops,
4 waiters, 500ns of work between signals, aarch64, MinSizeRel, median of 3:

m_min_wait                wall        signal() avg    signal() max
  no waiter        53.5 -> 42.6ms     348 -> 171ns
  batch            98.1 -> 36.1ms    1807 -> 179ns    127us -> 0.7us
  stream          261.0 -> 61.6ms    5777 -> 636ns    473us -> 142us

combining (stream)        wall        signal() avg    signal() worst
  before                 58.3ms          597ns            230us
  after                  48.2ms          348ns             17us

With zero work between signals the aggregate throughput goes the other way:
serialising on the spinlock lets one core keep the counter in its own L1 and run
long uncontended bursts, while the fast path has all eight adding to the same
line fairly. That burst throughput comes with a much worse worst-case signal()
and a large spread across vCPUs, and it evaporates as soon as there is any work
between signals, which is the case this optimisation targets.

References

• Independent of fix(thread): stop semaphore's out-of-order resume from deadlocking on the wait queue lock #1650 (the out-of-order resume deadlock fix): this PR is based
  on main and touches regions of semaphore::try_resume() disjoint from that
  fix, so the two can land in either order.