Flame Graph segment width seems to be weighted by sample count rather than time

This comes up particularly with off-cpu profiling, where one stack sample (when a thread blocks on IO or mutex) might represent a large wall-clock duration.

Compare this screenshot, where a segment has 237 samples and takes 49ms:


With this screenshot, where a segment has 75 samples and takes 9600ms:


I'd expect the 9600ms section to be about 9600/49=195 times larger, but instead the 49ms span is wider.

Here's an offcpu profile to reproduce with:
[2021-09-17-200119506-obfuscated.firefox.json.gz](https://github.com/firefox-devtools/profiler/files/7182437/2021-09-17-200119506-obfuscated.firefox.json.gz)

This was generated using Android simpleperf using off-cpu tracing 4000Hz for 30s:

```
$ simpleperf/app_profiler.py -p com.google.android.apps.maps -r "-f 4000 -g -e cpu-clock --trace-offcpu --duration 30" --activity com.google.android.maps.MapsActivity --skip_collect_binaries
```

Then converted to firefox profiler format.

┆Issue is synchronized with this [Jira Task](https://mozilla-hub.atlassian.net/browse/FP-437)