Clarify that the Rails console is an example of an unacceptably complex workaround by adding an example for severity::2

Why is this change being made?

This change is a part of the efforts in gitlab-com/support/support-team-meta#5936 (closed) to Reduce the reliance on required running of gitlab-rails console.

In the Severity section, we note that severity2 is for a "Broken feature with an unacceptably complex workaround".

This change clarifies that a workaround that requires the usage of gitlab-rails console is an example of an unacceptably complex workaround.

Increasingly, we hear from customers that needing to use the GitLab Rails Console to fix a problem is not acceptable. GitLab Dedicated customers do not have the option to implement workarounds that requires the usage of the GitLab Rails Console.

By clarifying that the usage of the Rails console constitutes an unacceptably complex workaround, this MR should help to ensure that the severity of issues matches the impact experienced by customers. This should help us to understand customer needs more clearly and prioritize to achieve results appropriately.

See gitlab-com/support/support-team-meta#5615 and gitlab-com/support/support-team-meta#5936 (closed) for notes and more conversation from the Gitlab Support team on why this is important.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

---