Per-signal FSDB size and writer CPU without per-signal API: dump-size delta via UCLI fsdbDumpvars, no recompile

The FSDB reader API does not expose per-signal stored bytes. A clean way to get bytes/change and writer CPU/change for a few signals:

1. Do not recompile. Run the existing simv with -ucli -do spec.tcl. In the Tcl use documented commands: fsdbDumpfile out.fsdb, then one fsdbDumpvars 0 {tb.u_soc.g_cl[2].u_cluster.s0} per signal (braces protect generate brackets in Tcl), then run and quit. VCS W-2024.09 printed "Dumping the signal (...)" for each one. A depth/IO spec also works: fsdbDumpvars 1 tb +all + fsdbDumpvars 4 tb +IO_Only. 2. Also run the same spec dumping one 1-bit, almost-static signal (e.g. reset) as the dummy, plus a UCLI no-dump run (run; quit) as the CPU baseline, so the UCLI start-up is identical. Alternate the runs (nodump, N-sig, dummy) x3. 3. bytes/change = (size(N sigs) - size(dummy)) / changes. Count the changes through the reader. fsdbdebug -top_n_var 0 listed nothing for wide packed structs dumped alone, because it lists struct members only. 4. CPU: use /usr/bin/time -v (utime + stime, all threads). Wall time hides the dumper threads.

Measured, 8 x 512-bit structs changing every cycle, 1M cycles, Xeon 4216: - size: 1.344 B/change; - writer CPU: 0.78-0.95 us/change. The dummy-vs-nodump noise was about +-1 s on a ~105 s run; the signal was 6.2-7.6 s. - The 2 dumper threads alone: ~0.55 us/change. - For comparison, a full +all dump of the same design cost ~0.37 us per stored change.

Also, +fsdb+consumer_thread_num=2/4 made the +all file 16-24% LARGER (331/308 MB vs 266 MB) at the same wall time. +fsdb+no_parallel kept the size but tripled wall time.