Move `issue_type` to separate table to support user creation of types

Based on Customizable Issue Types, we need to support customers being able to create their own types.

Currently our issues table contains an enum field (int2), issue_type, which supports 3 values at the moment:

  enum issue_type: {
    issue: 0,
    incident: 1,
    test_case: 2 ## EE-only
  }

In order for a user to be able to create their own types, with associated metadata and future customizations, we need to place these types in their own table, something like issue_types, or issue_custom_types

issues_type
id
title
icon_id
description
description_html
cached_markdown_version
group_id

Assumptions and questions

Scope

Based on the current description in Customizable Issue Types

Within a group (the top most parent group), CRUD types within an "issue types" list.

So the intent is to limit this to the top level group/namespace, and would dictate all the issues types for any issues below that.

The group_id column is what ties those together.

Defaults

Based on the current description in Customizable Issue Types

Defaults:

• Feature
• Bug
• Issue
• Enhancement
• Tech Debt
• Incident

We can provide default issue types out of the box for the parent(any?) group.

• are these intended to be immediately available, or only if the customer opts-in?
• might make sense to have these be opt-in - a button would trigger their creation for a group.
• we should probably keep the base level issue type as a way for the customer to only use that if they want, or not use the defaults at all, but their own custom ones.