Split out uploaded package checks into their own library/CLI

[emmatyping-nv]

What's the problem this feature will solve? Currently, there is no way to check if a package will pass the upload API checks. While there are other solutions that will hopefully eventually partially solve this such as PEP 694 and https://github.com/pypi/warehouse/issues/5865, having a CLI tool that checks a package will pass the pypi.org upload checks will allow users to verify their packages before release time, while not adding new strain on PyPI resources.

Describe the solution you'd like The package checks in https://github.com/pypi/warehouse/blob/main/warehouse/forklift/legacy.py will be refactored into a library/CLI in this repo. Warehouse will add this library as a dependency.

I want to be very careful that the refactored checks work the same and don't break anything, so I'm thinking of doing the following migration path:

1. checks are refactored to library ("library checks"), while keeping the existing checks ("current checks")
2. library checks are added such that they will not cause a rejection of upload, logging any failures if it disagrees with current checks
3. (optional) switch the library checks to be the primary checks, still logging any differences in failures (hopefully this doesn't happen)
4. Remove the current checks and only use the new library checks

This makes sure there is a low likelihood for the refactoring to cause new rejections that wouldn't happen from the current upload API checks.

Additional context

A few questions:

1. what should I name the library/CLI? I was going to go for a descriptive name pypi-upload-checks
2. is there a particular build backend I should use? I was going to use hatch/hatchling by default but I'm happy to defer to setuptools or some other backend.
3. how should shared dependencies be managed? Right now, I see requirements files locked via pip-tools for warehouse. I presume the versions should be kept the same for the shared dependencies (packaging, readme-renderer, etc.). I suppose I could customize the build to read these dependencies from the locked requirements files, but that seems a little hacky.