Draft: Constant Work Item Type IDs: flag nonconforming ID records

What does this MR do and why?

For Cells architecture, Work Items need to have a constant ID for each type. This MR is the start of migrating installations with a non-constant IDs for default work item types.

The biggest part of this work is migrating over the foreign keys in the issues table, and moving things over in such a way that the work items still function.

See #461487 (comment 1919921112) for overall strategy.

Details:

• Add new Work Item Types with negative IDs
• Add application logic such that we can support either the negative ID or the positive ID for a particular Work Item. This ensures we can move foreign keys in the Issues table and the work item type with the matching name will still be found.
  • Update code such that work_item.requirement? or work_item.objective? still function.
  • Update ::WorkItems::Type.default_by_type(:epic).id logic to include negative ID inclusion
  • Ensure work item features such as widgets, type change constraints etc still function even when negative work item IDs are thrown in the mix.

MR acceptance checklist

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

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Related to #461487