Adding support for additional context / dimensions in the crash report

[nicholaschen]

The current web reporting payload contains context from the client at time of the crash. additional contextual information would help with debugging, primarily:

• If the tab / app was in the foreground at time of crash

Other nice-to-have context information:

• A signal for the amount of memory in use before the crash occurred
• The last known JS/WASM/Chrome execution frame
• How many other pages shared this process? (i.e. Is it possible that another page caused the crash? Or was it a shared worker process?)

[clelland]

I think that background/foreground status is certainly possible. JS stack traces are being tracked in #12, and should at least be included in "unresponsive" reports.

Memory and number-of-shared-pages may have privacy issues, and I'm not sure that we can include those. Especially for browsers without full site/process isolation, this could easily leak information about a user's activity on unrelated websites.