Optimize TimeHistogram

[emilk]

• Part of The 1M index entries problem #5967

The TimeHistogram is what enables this view in the time panel:

When we have a lot of entires this becomes a memory hog because each time entry is cached in multiple TimeHistograms: one for the component, one for the parent Entity, and then once more for each ancestor Entity.

Suggested solution

Now that everything is chunks, we should have a very chunk-centric solution to this. Each chunk should have rough statistics of its contents per component, per timelines. At least number of entries for each column, and the time span on each timeline. We could optionally have a time histogram computer per chunk (stored in a cache, evicted when not read). Each ChunkTimeHistogram is either a full TimeHistogram (same as current code) or just "number of entries over this time span", if the number of entries is above some threshold (e.g. 100k).

Then each frame we do:

• Find all chunks that overlap the current query (time-range + entity path)
• Get the ChunkTimeHistogram for each chunk
• Merge them into a visual histogram, and render that

When hovering, we just do a range query (hovered time ± 3pixels) so we can do a tooltip.