Need forward-looking design plan for mutli_row_track and rect-track- related features

[natduca]

We have a bunch of timeline-related features that are upcoming at various urgency levels. Amongst them:

• Better display of netlog slices as exist today [less vertical space]
• Overhaul of of net data to be closer to how devtools "Network"
• Better display of input latency events [not enough vertical space between them]
• Hover-over-slices to see details
• Click on a slice to expand/contract it
• Critical path view // associated events view #1202

These all imply evolution to the existing track systems which are mostly around the multi-row-track and the rect-track. In some conservative interpretations of the future, we make minor tweaks and say no to a few more sophisticated ideas. In the more liberal futures, we overhaul how we render async slices and adopt a Box-with-State concept.

Lets block work on these things on us discussing, on this bug, a future architecture that plots a middle ground between the extreme "do nothing" and "rewrite everything" extremes.

[natduca]

@dj2 @benshayden I will drive this for now, but lets all collaborate on this. Outcome is for us to have a design doc that encodes our architectural roadmap for all these features.

[natduca]

A sketch I came up with that deals with the fracitonal heights issue. This is not the only issue face, but it illustrates one challenge that we must discuss and move forward.

https://docs.google.com/drawings/d/1SnBFqY2L_AWQTE76rFXyeut-5W7dPLHLMN0HnPMVoxE/edit

[natduca]

Closing in favor of #1780 which is our omnibus tracking bug.