Rewrite! #78
Description
I think it's time to rewrite tlparse.
My biggest problem with tlparse's architecture right now is that it goes straight from the log file to rendered files. This was ~fine while we weren't really doing any nontrivial rendering for log entries, but it's a real slog for anything that needs more specialized UI. You can kind of see this with how symbolic_shape_specialization_index was bodged in so that we could put all of the specializations in one place, so that we could correctly plop them into compilation metrics when we rendered that page. I don't want to have twenty more indexes for each other nontrivial thing I want to render. The single shot architecture has also meant that even though we have describe_* entries I have never bothered actually writing the rendering code for them.
The simplest fix is to introduce an intermediate rendering data structure (JSON compatible) that intermediates between the log file and the rendering code. It can undo all the string interning, be collated per compile id, and all the actual source code dumps are gone (those have been moved to file system by the rendering). It can mostly reuse all the same data structures from regular tlparse, just rearranged to reflect how we want them to be laid out on the page.
I have some uncertainty about the UI itself. I like the simplicity and performance of plain HTML/JS. But I do not think TinyTemplate is a very good HTML rendering framework, it just happened to be easy for me to get working as a Rust noob. I care a bit about minimizing boilerplate and making it easy to make UI tweaks. So maybe we should bite the bullet and write a React frontend that ingests the JSON data structure? Not sure.