This ensures that the vulnerability modal always has an actions
area/footer, even if the vulnerability it's displaying has been resolved
(which can only happen within MRs).

Therefore, this should only have a visual effect on vulnerabilities
fixed within a particular MR, when viewing that MR. The vulnerability
modal is used elsewhere, for instance the Project Security Dashboard,
but in those other places, vulnerabilities can't be "fixed", and so this
should have no effect there.

Before this change, fixed vulnerabilities couldn't be interacted with at
all, since their actions footer wasn't displayed. This meant that the
user could not:
 - dismiss the vulnerability
 - create an issue for the vulnerability
 - create a merge request to fix the vulnerability
 - download a patch to fix the vulnerability

All of these restrictions still make sense, I think. The problem was
that they weren't allowed implicitly before, whereas now they're
disallowed explicitly.

Some more details about the changes:
 - The modal determines what to display based on a handful of `can*`
   props, e.g., `canDismissVulnerability`. These are simply permissions
   about vulnerabilities in general for the current user, and not
   specific to any given vulnerability. Since it's not meaningful to
   dismiss a resolved vulnerability, these permissions have been
   augmented to consider the current status of the vulnerability, via
   the new `can*ThisVulnerability` computed properties.
 - An unused computed prop `renderSolutionCard` was removed. Some test
   code was cleaned up around the `SolutionCard` (preferring finding
   elements via refs and component classes over `js-*` classes).
 - Added/clarified some tests around when and why the modal rendered the
   footer. Previously, permissions were conflated with simply the
   existence of the footer.

See https://gitlab.com/gitlab-org/gitlab/issues/32767.