Add support for "hard" links between Merge Requests and Work Items

The Problem

Today, MRs can be related to work items in a few different ways:

• Mentioning the work item ID in a commit message
• Creating an MR from a work item
• Using the supported syntax of References: #123 or Closes: #123
• Referencing a work item in a comment in an MR

The problem with this:

• Any MR can be loosely related to any work item.
• The MR may or may not implement/resolve/fix the goals outlined in the work item.
• There is no programmatic way to determine if an MR contributes to a work item or not.
• This has sweeping ramifications for things like:
  • Compliance & Traceability: No way to determine with certainty which code changes were made according to which work items requested them?
  • Value Stream Analytics: No way to determine with certainty the cycle time of a work item if there can be many MRs related to the work item that did not actually deliver what was planned in the work item.

The Opportunity

If there was a distinction between a related MR and an MR which implements all or a portion of a work item, we could do neat things like:

• Accurate audit / change management history
• Surface more context from MRs automatically within a work item (ex: review app button, automatically infer and surface versions / tags from the relevant code changes)
• More accurate value stream analytics
• Surface more context from a work item within an MR (ex: Design management, keep meta-data like milestones in sync, and more)

Proposal

• Extend support for the "relationship" widget (#229731 (closed)) to MRs.
• MRs can be related or "children" of work items.
• Relationships can be updated/broken from either a Work Item or an MR.