Conflict resolution for multiple Domain Aliases on same environment

Problem/Motivation

If a given environment has multiple domain aliases for the same environment, it will choose one without error.

The purpose of this ticket is to at the very least document what the current conflict resolution behavior is.

Secondly, it would be ideal to support a method for conflict resolution.

Steps to reproduce

1. Install domain_alias module
2. Create a domain "www.example.com"
3. Setup these aliases on that domain for the DEV environment in this order:
- dev.example.com
- exampledev.prod.acquia-sites.com
4. Setup these aliases on that domain for the STAGE environment in this order:
- exampletest.prod.acquia-sites.com
- stg.example.com
5. Deploy these changes to DEV and STAGE
6. SSH into DEV and notice the Domain loads to "dev.example.com"
drush php:cli -l https://dev.example.com
>>> echo \Drupal::entityTypeManager()->getStorage("domain")->load("example_com")->get("hostname") . "\n";
dev.example.com
7. SSH into STAGE and notice the Domain loads to "exampletest.prod.acquia-sites.com"
drush php:cli -l https://stg.example.com
>>> echo \Drupal::entityTypeManager()->getStorage("domain")->load("example_com")->get("hostname") . "\n";
exampletest.prod.acquia-sites.com"

The human doing this might expect "stg.example.com" to load because that is the domain passed via the CLI. However, it's not!

Proposed resolution

Documenting the Current Behavior

This is the assumption about the current resolution behavior, this should be verified / proven, e.g. with a test:
- When a Domain entity loads, domain alias module will overload that in domain_alias_domain_load, see https://git.drupalcode.org/project/domain/-/blob/8.x-1.x/domain_alias/do...
- The information it overloads it with is determined by the first entry it finds in the config table

Supporting Conflict Resolution

TBD: Identify how someone can hook in and resolve conflicts in their own way. In the example above, it might be someone wants the alias specified by the Drush domain to take over.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD