High memory usage for profiles with lots of tracks

The profiler seems to consume 838MB of memory with a profile that has 6000 tracks. I can't upload the profile as it's from a corp workstation, but I'll try to recreate one at home later (I believe anything that has the same amount of track should repro).

Chrome's sampling allocation profiler points to getCPUProcessedThreads as the likely culprit. This instantiates the selector graph for all threads in the profile, and the memory cost of creating the selector themselves seem to be dominating.

I found some [low hanging fruits](https://github.com/ishitatsuyuki/reselect/commit/2f5bc47f78cd5c9a6e8d2fb71c8bf0e426e6af87) in reselect which cuts the memory usage down to 658MB. However, I doubt I can go much further than that.

For long term, I think we might want one of:
- Eagerly running the selector logic for getCPUProcessedThreads, without the memory overhead of creating all the selectors
- Share some of the selector logic across all parametizations, e.g. how dependencies can be computed. The dependency graph cannot be shared between parametizations, but they can be instantiated more lazily than now.

┆Issue is synchronized with this [Jira Task](https://mozilla-hub.atlassian.net/browse/FP-799)