bug-1830954: add support for has_guard_page_access

[willkg]

This adds is_likely_guard_page to the stackwalker output part of the processed crash schema.

It also adds a new top-level has_guard_page_access protected field. This is true iff there's at least one memory access where is_likely_guard_page is true.

These fields are marked protected because there are security concerns with this data.

Example crash reports:

• 8dd52551-692d-45ff-82d0-9ab000240228
• a5875ef2-5cc1-4fdd-bbab-0b1400240229
• 7c66167c-de29-4b8f-85c3-1c7db0240228
• 456b3a73-1607-4487-9814-929700240228
• c52e0b31-5a34-4937-a922-b97c30240228

To test:

1. rebuild local dev environment
2. process crash reports
3. open browser in webapp (not logged in)
   1. view crash report
      1. verify you can't see "Has guard page access: true" in "Details" tab
      2. verify you can't see is_likely_guard_page in report view "Raw data and minidumps" tab
      3. verify you can't see has_guard_page_access in processed crash
   2. view super search
      1. verify you can't search using has_guard_page_access field
4. log into webapp
   1. view crash report
      1. verify you can't see "Has guard page access: true" in "Details" tab
      2. verify you CAN see is_likely_guard_page in report view "Raw data and minidumps" tab
      3. verify you CAN see has_guard_page_access in processed crash
   2. view super search
      1. verify you CAN search using has_guard_page_access field

[relud]

r+wc

[willkg]

^^^ I amended and force-pushed, but the only difference is removing the [ and ] in the any argument.

[willkg]

Thank you!