src: add event loop based metrics into node

[pabloerhard]

Adds an opt in into monitorEventLoopDelay(), this option adds support for per iteration sampling using libuv hooks, while preserving the existing timer based approach.

When the new samplePerIteration option is set to true, monitorEventLoopDelay() samples directly from event loop iterations instead of using the interval timer. When samplePerIteration is omitted or false, the existing interval based implementation remains unchanged, including resolution handling and the older interval based trace counters.

Motivation
The interval based implementation has two limitations that the new option addresses:

• Inaccurate measurements. Delay was approximated from a timer dispatch jitter (RecordDelta() between timer ticks) rather than measured from the loop itself. Samples had an implicit floor of resolution ms and could miss delays that didn't happen to coincide with a timer tick.
• Wasteful wake ups. The timer forced the event loop to iterate every resolution ms just to record a sample, even when the application was otherwise idle and no one was reading the histogram.

This is an alternative implementation to the one in #62934

This PR directly addresses the following issue #56064

[codecov]

Codecov Report

❌ Patch coverage is 78.51852% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.64%. Comparing base (80e0f14) to head (27ead1e).
⚠️ Report is 109 commits behind head on main.

Files with missing lines	Patch %	Lines
src/histogram.cc	79.50%	11 Missing and 14 partials ⚠️
src/histogram.h	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62935      +/-   ##
==========================================
- Coverage   89.65%   89.64%   -0.02%     
==========================================
  Files         708      708              
  Lines      220413   220546     +133     
  Branches    42275    42290      +15     
==========================================
+ Hits       197607   197702      +95     
- Misses      14658    14675      +17     
- Partials     8148     8169      +21     

Files with missing lines	Coverage Δ
lib/internal/perf/event_loop_delay.js	95.95% <100.00%> (+0.12%)	⬆️
src/node_perf.cc	86.61% <100.00%> (+0.22%)	⬆️
src/histogram.h	50.00% <0.00%> (-10.00%)	⬇️
src/histogram.cc	79.08% <79.50%> (+0.12%)	⬆️

... and 33 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[BridgeAR]

Pretty much LGTM, just left two nits. I would feel more comfortable with someone else reviewing it as well.

@addaleax @jasnell maybe?

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/74208/

[BridgeAR]

LGTM, while I would still like to get another LG who works on CPP frequently

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/74238/

[jasnell]

Why the rename? the intent here was for it to be named generically so that it could potentially be used for things other than just event loop delay monitoring.

[pabloerhard]

The rename was meant to avoid documenting that monitorEventLoopDelay() strictly returns an IntervalHistogram, this because with the new samplePerIteration option the native backing is no longer always interval based. Leaving the documented type as IntervalHistogram felt misleading considering the same API can be backed by either an iteration or interval based sampling.

My first approach was to document that monitorEventLoopDelay() returns {IntervalHistogram|IterationHistogram}, but that felt redundant considering both modes expose the same JS API shape and only differ in how samples are collected. That said, maybe this approach is a better option if we want to maintain IntervalHistogram as a generic documented type while also introducing IterationHistogram.