Investigate how to prevent data inconsistency between migration type

Ref: https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues/7351

Problem

As explained in #495123 (comment 2288539123) we introduced a bug in a post migration and created a fix as a regular migration.

This led to data inconsistency and some self-managed and Dedicated customers could not upgrade successfully.

For Dedicated, this has significant impact on agreed availability because delayed post-deployment migrations can cause maintenance to run beyond the planned maintenance windows.

If users are skipping the PDMs to be executed at a later time, then the regular migration is executed first and it doesn't have the constraint to be removed since it's added after it, when the PDMs are executed.

Solution

Improve the tooling for helping reviewers to easily catch this types of problems by adding a Danger rule that activates on new migrations introduced on backporting merge requests. The rule should add a comment like this one:

Please make sure that the migration is of an [appropriate type](https://docs.gitlab.com/development/migration_style_guide/#choose-an-appropriate-migration-type) and if it's supposed to be executed before or after an existing migration then it must be of the same type.

This won't catch all of the problems related to merge request dependencies, but it would have prevented us from causing this problem.