Fix prod_set div-by-zero on fast CPUs and nice -n -20 EPERM in unprivileged guests

[charles-typ]

Summary:
Two robustness fixes to the WDL prod_set runner, both hit while running the
suite on a fast Arm (Olympus) host and inside an unprivileged VM guest.

Problem 1 - scoring crash on fast cores. concurrency_concurrent_hash_map_bench
and synchronization_lifo_sem_bench fail with "score: error (float division by
zero)". On fast CPUs some sub-metrics (e.g. single_thread_lifo_trypost/trywait,
CHM empty()/size() ops) complete in 0 ns, below the timer resolution.
compute_score_from_time then does sum_baseline[key] / sum_c[key] and raises
ZeroDivisionError, losing the whole workload's score. A 0 ns sample is not a
real data point, so we skip those keys (the geomean of the remaining
sub-metrics is still valid). If every sub-metric is 0, geomean([]) raises and
the existing main() handler already reports a per-benchmark error without
aborting the set.

Problem 2 - nice -n -20 EPERM. run_prod.sh hard-codes nice -n -20, which needs
root/CAP_SYS_NICE. In an unprivileged environment (e.g. a VM guest) every
workload invocation fails with EPERM. We now probe nice -n -20 once and fall
back to default priority when it is not permitted, so the run proceeds instead
of failing.

Differential Revision: D111817632

[meta-codesync]

@charles-typ has exported this pull request. If you are a Meta employee, you can view the originating Diff in D111817632.