feat: generate flamegraphs on demand

[ivan-tymoshenko]

This PR refactors the flamegraphs plugin from an always-on profiling model to an on-demand architecture. Instead of continuously profiling all workers at fixed intervals, profiling now starts only when explicitly
requested (via alerts, health signals, or WebSocket commands) and automatically stops when idle.

Previously, workers were profiled continuously and the eluThreshold setting determined whether profiles should be captured based on Event Loop Utilization. With on-demand profiling, the ELU threshold logic has been
removed entirely—profiles are now generated whenever requested, regardless of current utilization metrics. This gives callers explicit control over when profiling occurs rather than relying on automatic threshold-based
triggering.

Multiple profile requests are queued and associated with generated profiles based on timestamps. Profilers automatically stop after an idle period if no new requests arrive, preventing unnecessary resource consumption.

[Qard]

Minor suggestion, but otherwise LGTM.

[Qard]

Rather than using plain await sleep(...) all over the place, delaying test completions longer than may actually be necessary, we might want to use a Promise.race(...) pattern for waiting on a completion condition with a timeout for failure. Something like:

await Promise.race([
  sleep(1500).then(() => Promise.reject('timeout')),
  profileReceivedPromise
])

[mcollina]

lgtm