Change how the processed format stores which pages correspond to a thread / process (stop relying on innerWindowID in the frameTable)

[mstange]

When you select a page in the page selector dropdown, we restrict the visible threads to threads from processes which contain frames or markers for the selected page.

Can we avoid checking the frameTable? It would be nice to be able to remove the innerWindowID information from the frameTable.

Instead, we could have a list of page indexes for each process. We don't really have a good way to store per-process data at the moment, so we could duplicate the data on each thread, e.g. like this:

{
  meta: { ... },
  pages: [
    {
      tabID: 124,
      innerWindowID: 47244640266,
      url: "https://bugzilla.mozilla.org/show_bug.cgi?id=1962217",
      ...
    },
    ...
  ],
  threads: [
    {
      processPages: [0, 4, 5, 8], // the page indexes for any pages used by the process this thread belongs to
      // ...
    }
  ]
}

Where would this data come from?

• When upgrading old processed profiles, the upgrader will probably need to recover this data by checking the markers and samples like we do today.
• When converting a Gecko profile into the processed format, we already start with per-process pages: The Gecko profile format has a separate full profile JSON for each process, and each of those has their own pages array. We accumulate all those pages arrays into one global pages array. When we do this, we can just remember which process the pages came from.

The new format is also something we'll need if we want to combine the frame tables from multiple threads into a global frame table.

┆Issue is synchronized with this Jira Task