[WIP] Parallel frontend display for the site

[heinwol]

It got pretty big despite not being finished still, so i decided to open a pr just to track things.

The work is based primarily on #2421 and is the second part of bringing parallel frontend metrics to rustc-perf with the first being #2491.

While the most important obvious part is adding a new dimension (new url params, database queries, deserialization, filters, etc.) some structural changes were made.

1. The main being strict type enforcement of nested records of data received from the database. Recall having the following nesting structure before:

   benchmark -> profile -> scenario -> series
   

   This was represented as Dict<Dict<Dict<Series>>>. @ azhogin introduced this change:

   benchmark -> profile -> parallel -> scenario -> series
   

   which was represented as Dict<Dict<Dict<Dict<Series>>>> respectively. Recall also it's been decided in Parallel frontend compiler support (perf backend only) #2491 to transpose this layout to

   benchmark -> profile -> scenario -> frontend_threads -> series
   

   Now imagine the amount of bugs and inconsistencies i encountered when trying to apply this change to simple nested records. I simply couldn't have caught them without the linter warning me what was wrong where. Therefore a new type-safe structure is introduced as an attempt to mitigate this errors now and in the future.
2. Due to inherent typescript's lack of ability to enforce typing for record keys and operations on entries, a specific wrapper class was introduced (currently residing in site/frontend/src/utils/map-wrapper.ts). It's a Map underneath with... well, more type safety. We extend this class as a form of newtype pattern, like

   export class ProfileSeries extends MapWrapper<Profile, ScenarioSeries>

   for type enforcement.
3. Said Map's keys are also typed. Handling of said keys in different contexts varied. Sometimes we needed profile to be lowercased, sometimes capitalized. And we had no idea what format our input data was in. This is especially confusing to a person not familiar with the codebase. So it's necessary to enforce a single format (like Profile or FrontendThreads) that is some kind of string wrapper, with proper casting (like site/frontend/src/graph/data.ts: toProfile function).
4. rename site/frontend/src/typings/{vue.ts -> vue.d.ts} to satisfy Deno linter and follow TS conventions.

Of course, all this goes beyond just adding a new dimension. Unfortunately, i wasn't able to do otherwise as i was just lost in lots of bugs arising out of the blue before bringing a decent amount of lint time safety.

Some changes made by @ azhogin are left intact, for instance additional error handling in site/frontend/src/pages/detailed-query/page.vue as well as in many other places.

---

TODO (needs discussion)

• well, it still doesn't work 😅
• integrate renaming from Rename frontend_threads to Threads #2512;
• consistent string enumeration values for map keys / display data (like type Scenario = "full" | "incr-full" | ...) instead of branding. Will need other conversion functions;
• move type definitions from site/frontend/src/graph/data.ts: they're used outside of graphs context;
• further fixing inconsistencies in string enumerations usage;
  • maybe we could remove lots of checks in site/frontend/src/pages/compare/compile/common.ts (like computeCompileComparisonsWithNonRelevant().profileFilter()) as a result;
• extend changes symmetrically to runtime benchmarks.

[Kobzol]

I didn't look at the code yet, but I think that we should do this incrementally. Taking a look at how the last benchmark axis (target) was added should be useful. The first step is to show the frontend threads in the compare page, as that's the most important place. The PR that did this for target is #2272 - it has less than 100 lines (just for comparison of how complex that should be).