Restrict security heatmap to vulnerabilities

Problem to solve

The security heatmap (example) displays "all" security issues, including non-vulnerability feature proposals. It seems that was originally done because it was the easiest way to be certain of displaying all vulnerability issues. That causes a couple problems:

1. Distraction/noise. Fixing security vulnerabilities is our #1 priority. Displaying non-vulnerability issues in the security heatmap distracts from the most important issues. We don't display extra stuff in the heatmaps for bugs and infradev issues, we shouldn't do it for vulnerabilities.
2. Process dysfunction. The x-axis of the heatmap is severity, and feature issues don't usually have a severity label, so feature issues would usually appear in the "No severity" column. Because Engineering Managers are responsible for ensuring all bug issues have a severity label, this often forced Engineering Managers to review feature issues that did not need to be reviewed. (In at least one case an EM assigned a severity label on a feature issue just so the issue didn't appear to be an un-triaged bug in future triage reports.)

We now have an easier way to identify vulnerability issues: using the vulnerability label.

What does this MR do

This changes the heatmap to display only security vulnerabilities.

Action items

• (If applicable) Add documentation to the handbook pages for Triage Operations =>
• (If applicable) Identify the affected groups and how to communicate to them:
  • /cc @person_or_group =>
  • Relevant Slack channels =>
  • Week-in-review