Expose work item widgets as separate fields

What does this MR do and why?

This makes it easier for the frontend to access a specific widget directly instead of iterating over the widgets array.

1. This introduces a features field under the workItem type.
2. This will contain each widget as a field named after the widget name (without any "widget" suffix).
3. When a widget isn't available for the current work item, the widget field will return null. This is different from a null value within the widget. For example, when features.weight is null, it means the work item does not support weights. If features.weight.weight is null, then it means the work item supports weights but doesn't have a value set.

Concerns

1. The field name features. This is another term we're introducing here and I don't know if there is a better name. We can't use widgets because that's the current field that returns the array of supported widgets. Related to: !214524 (comment 2930757469)

2. Widget names and widget field names that are the same can be confusing. For example, we have features.assignees.assignees.

   We could add a suffix to the widget names so it becomes features.assigneesWidget.assignees. Though this seems a bit verbose.

   Another option would be to rename the fields under the widget. For example: features.assignees.users. This would take a lot more work and could also be confusing for users because we'd be returning fields that are different from the widgets returned by the existing workItem.widgets field (even though we probably want to deprecate that eventually). This will also be harder to implement because we can't reuse the same widget GraphQL type classes.

References

Related to #493472 (closed)

How to set up and validate locally

Example query:

{
  workItem(id: "gid://gitlab/WorkItem/21") {
    id
    title
    features {
      assignees {
        allowsMultipleAssignees
        assignees {
          nodes {
            name
          }
        }
      }
      description {
        description
        descriptionHtml
      }
      hierarchy {
        parent {
          id
          title
        }
        children {
          nodes {
            id
            title
          }
        }
      }
      color {
        color
        textColor
      }
    }
  }
}

Old query

{
  workItem(id: "gid://gitlab/WorkItem/21") {
    id
    title
    widgets {
      ... on WorkItemWidgetAssignees {
        allowsMultipleAssignees
        assignees {
          nodes {
            name
          }
        }
      }
      ... on WorkItemWidgetDescription {
        description
        descriptionHtml
      }
      ... on WorkItemWidgetHierarchy {
        parent {
          id
          title
        }
        children {
          nodes {
            id
            title
          }
        }
      }
      ... on WorkItemWidgetColor {
        color
        textColor
      }
    }
  }
}

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.