Waveform tracing overhead: compare cost per stored change, not overhead percent

When comparing simulation-time waveform capture mechanisms (a simulator's built-in trace, a custom trace backend, a DPI-based capture library) across designs, percent overhead vs a no-dump run is misleading on its own. It mostly reflects how busy the design is, not how efficient the mechanism is.

What worked: - Add two columns to every write table: changes per simulation-CPU-second (stored value changes from the output check, divided by the no-dump run's CPU-s), and extra CPU per stored change in ns for each arm. - In one comparison, two designs differed ~100x in change density while each mechanism's per-change cost differed by under 2x. Overhead ranged from a few percent to several hundred percent purely because of density. - Changes per cycle is not the right normaliser: simulation speed per cycle varies widely between designs. Normalise by simulation CPU time. - Per-change cost then tells you what to optimise (e.g. a call boundary per change vs batched capture), and density tells you which real workloads will hit it. - Profilers perturb timing: report profile sample shares, not profiled timings, and keep timed and profiled runs separate.