Support Relationships in CODEOWNERS (or Approval Rules)
<!--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>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=385209)
</details>
<!--IssueSummary end-->
### Proposal
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
Currently we can use [CODEOWNERS](https://docs.gitlab.com/ee/user/project/code_owners.html) to control the approvers for individual parts of the codebase, or [approval rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html) to cover more generic requirements. These are both all-or-nothing options with no granularity beyond mandatory or optional.
We would like to propose a mechanism is provided where relationships can be defined between elements of the code base, perhaps using an approach similar to [merge request approval segregation of duties](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties)
For example if we have a `CODEOWNERS` thus:
```plaintext
* @alice
/path/to/file-1 @bob @carol
/path/to/file-2 @dan
/path/to/file-3 @dan
/.gitlab/CODEOWNERS @erin
```
We would like to be able to specify a rule that
- if `file-1` is changed then `@bob` or `@carol` have to approve (existing CODEOWNERS capability)
- if `file-3` is changed then `@dan` has to approve (existing CODEOWNERS capability)
but
- if `file-2` is changed then `@dan` has to approve (existing CODEOWNERS capability) **and** one of `@bob` or `@carol` for *reasons*, e.g. because `file-1` is directly consuming `file-2` (proposed new approval rule capability)
At the moment there is no easy way to systemise these sorts of relationships leading to an incomplete approval chain.
issue