[New Feature]: Throw Validation-Domain when Github URLS don't strongly correlate to the PackageIdentifier

Description of the new feature/enhancement

For most packages that are hosted on GitHub, the PackageIdentifier is of the form Organization.RepoName where both the organization and the repo name have been normalized. For example, https://github.com/Example-Desktop/ExampleOne may end up as Example.ExampleOne while https://github.com/Example-Two/Package may end up as ExampleTwo.Package.

In the current state of the pipelines, any GitHub URL seems to pass validation without Validation-Domain, regardless of if they correlate to the package identifier. This means that a fork like https://github.com/denelon/Package could be submitted to the identifier Trenly.Package without ever throwing Validation-Domain. Given the standards already set in the repository, and the need for correct attribution, this should not be allowed.

Proposed technical implementation details (optional)

A new type of domain validation should be applied to GitHub URLs to ensure they point to a heuristically similar fork that the package identifier is claiming. Since it is possible for GitHub organizations to be renamed, or for there to be a genuine need for an identifier to not match the organization, there should be a way to apply a waiver.

It would be best if all GitHub URLs had to have a waiver which correlated the package identifier to a specific repository

No files, tests, or entry points are named. Start by locating the pipeline handling Validation-Domain for GitHub URLs, then review existing identifier checks and waiver mechanisms. Done should include a decided correlation rule, an explicit waiver path, and coverage for matching, mismatching, renamed, and waived repositories.