Create database constraints for approver group names and migrate existing data
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=32307)
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=32307)
</details>
<!--IssueSummary end-->
## Summary
We recently [added validation](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/16216) to prevent users creating approver groups with the same name.
As part of this, we should also create database-level constraints and migrate existing data that have duplicates. See: https://gitlab.com/gitlab-org/gitlab/merge_requests/16216#note_213395600
## Improvements
Prevents inconsistent data state at the database level.
## Risks
Data migration might be tricky?
## Involved components
<!--
List files or directories that will be changed by the refactoring.
-->
## Optional: Intended side effects
<!--
If the refactoring involves changes apart from the main improvements (such as a better UI), list them here.
It may be a good idea to create separate issues and link them here.
-->
## Optional: Missing test coverage
<!--
If you are aware of tests that need to be written or adjusted apart from unit tests for the changed components,
please list them here.
-->
issue