Use one standalone issue tracker for all GitLab issues

Background

• We are planning to move toward one codebase in the near future.
• GitLab's scope is broadening. We have GitLab.com versus self-hosted. We have different tiers. We have different distributions. See https://about.gitlab.com/handbook/marketing/product-marketing/#tiers.
• Based on the specific tier, we need to specify different requirements differently when working on features.

Proposal

• For all GitLab-related issues, use one standalone issue tracker in a new project. So the issue tracker would live at: https://gitlab.com/gitlab-org/gitlab-issues/issues
• Inside each issue, specify the different requirements/behavior for the different tiers.
• Attach one or multiple merge requests as needed to that one issue. For example, you might need separate CE or EE merge requests if a feature needs to touch both codebases.
• If a new change affects a GitLab user, it should probably be in this issue tracker, with little exceptions.
• For example, if there is a usage ping related change, and the CE distribution codebase, the EE distribution codebase, and the version.gitlab.com codebase all need changes, it would be one issue in this issue tracker. But you would have 3 merge requests attached to this one issue.
• Changes that are not part of GitLab would not be in this issue tracker. For example, if there is a change regarding any page of about.gitlab.com, that would not be in this tracker.

Benefits

• One location to have all discussions of the feature and one location to have SSOT on the requirements.
• No confusion that not all scenarios have been addressed since there's only one place where any information can be addressed.
• If we use a template (for example, a table) highlighting all cases, it forces people to consider all cases carefully.