Event delay calculations incorrect for threads with few events

If you look at event delays on non-mainthreads (which often have large gaps between actual samples) the delays shown can be wildly wrong - a Compositor thread with no sample hits for 7 seconds showed a 7-second delay. The event_delay array shows a few 0's, then many many samples with 'null', then a few 0's. That should be 0 delay for the entire time, not a 7 second delay.

See https://share.firefox.dev/3gZXOVz (subsetted from https://profiler.firefox.com/public/qjv5wwawmyym8yfd1r5mgekg2m7kf508ypnzxrg/marker-chart/?globalTrackOrder=11-0-1-2-3-4-5-6-7-8-9-10&hiddenGlobalTracks=1-2-3-4-5-6-7-8&hiddenLocalTracksByPid=11268-1-2&localTrackOrderByPid=8276-1-0~2708-0~11268-0-1-2~6372-0~&thread=14&v=5)

Probably something is incorrectly interpreting this as an event kept being executed when in fact no event was running. Probably related to the code for sample duplication if there were no wakeups (and thus it doesn't sample the event delay) combined with code that ignores nulls. The algorithm being used assumes there's a value recorded for each sample.

Just a guess; perhaps if the last sample was 0 and we're duplicating duplicate the 0 as well? I'm not certain that captures all the issues here, but perhaps

canova

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