Align Node V8 progress handling with Chromium

[Andarist]

Note: there is no crash report associated with this. It's just a reported progress mismatch + inconsistent data between basic and scan data that leads to a backend assert in ensureFramePoint/getPointStack. With inconsistent data, our machinery fails to narrow down the enclosing frame points for a bookmark point.

We've observed progress mismatches. In the recording af25ba61-465b-4ccb-91ef-183926364d7d the mismatch goes away when starting the scan later, see the manifest diff (lower startProgress mismatches when the higher one stops to mismatch):

{
  "kind": "scanRecording",
  "endpoint": { "checkpoint": 469, "progress": 2030423 },
-  "startProgress": 2027916,
+  "startProgress": 2027917,
  "getGenerators": true,
  "getDependencies": true,
  "writeScanDataFile": true
}

The lower one includes the tail of some Playwright async frame, the higher one "skips" over it.

It's unclear what the root cause actually is. But I found some optimization-related divergences around progress tracking when comparing things to the current Chromium source code. I think it's worth aligning to the more heavily used and tested Chromium code either way and there is a real chance this will address the issue we have found.

Chromium commits effectively cherry-picked/mirrored:

• 6183d3132d7f - Add env var to assert on JS progress changes (#68)
• 3104d7cad00f - Fix build breaks
• 2055467196a - RUN-2232: Make OnProgressReached a no-op when events disallowed (#166)

Related context, but not newly cherry-picked:

• 4349d6d17f42 - introduced Chromium's optimized counter path; Node already had its own equivalent.
• a7cb52b8c2e1 - introduced Chromium's direct progress-reached callback; Node already had the direct callback path.

relates to: https://hub.replay.io/issues/issue/DEBU-6