[web] Force a GC before each benchmark reload to keep /dev/shm from filling up (#193822)

`Linux web_benchmarks_ddc` occasionally goes silent right after a
benchmark reloads the page and stays that way until the 60-minute build
timeout.

Every reload detaches the previous document, and each detached document
keeps ~2.5 GB of unlinked `/dev/shm` segments alive until a major GC
collects it. Chrome doesn't schedule that GC on its own (the JS heap
barely grows between reloads), so `/dev/shm` (a tmpfs capped at half the
RAM, 15 GB on the bots) climbs ~2.5 GB per reload and only drops when a
GC happens to run. Six reloads without one fill it up, and the ~1200 DDC
script requests of the next benchmark fail with:

```
Failed to load resource: net::ERR_INSUFFICIENT_RESOURCES
Failed to load DDC scripts after 6 tries
```

Example CI failures:
- https://ci.chromium.org/b/8669194409660736177
- https://ci.chromium.org/b/8669101540217564753
- https://ci.chromium.org/b/8669090225917741873

`/dev/shm` growth measured on an instrumented try run
(https://ci.chromium.org/b/8669026420082427889): 3% → 20% → 36% → 53% →
69% → 86% over reloads #21–#26, then 100% (140 KB free) at the first
refused request. Forcing a GC at 86% drops it to 1% in ~2.5s
(https://ci.chromium.org/b/8669022530080696465). It was 0 B at task
start and after Chrome exits on every bot sampled, so nothing
accumulates across runs.

This PR calls `HeapProfiler.collectGarbage` over CDP right before
handing the page the next benchmark name (after the previous results
were posted, before the reload), so at most one detached document is
alive at any time. 35/35 green try runs with the fix (e.g.
https://ci.chromium.org/b/8669018927607202977,
https://ci.chromium.org/b/8669017714155624401) vs ~10% failures without
it. The instrumented branch with the full investigation is
https://github.com/mdebbar/flutter/tree/deflake_linux_web_benchmarks.

Fixes https://github.com/flutter/flutter/issues/193727