Reject invalid classifiers, warn on license classifiers

[woodruffw]

Summary

This makes two changes to our handling of trove classifiers in uv's build backend:

1. We now reject malformed trove classifiers. I've done this by adding a Classifier newtype that parses and rejects anything that looks wrong (there's no formal grammar for classifiers, so this is a pretty primitive check, but it should be enough to preempt most common user errors). We don't use an allowlist at the moment, although in principle we could do that as well/instead.
2. We now emit a user warning on any license classifiers, since these have been deprecated since PEP 639 was accepted. I've added this within PyProjectToml::license_metadata since in the future we'll also want to produce a hard error when license classifiers are present and new-style structured license metadata is also present. That change will require a breaking release however.

Closes #16354.

Test Plan

I've added some new unit tests for this, plus an integration test for the user warning.

[woodruffw]

Flagging: I wrote it this way because I'm allergic to intermediate allocations, and the most "obvious" form would involve one (via Vec<&str>). Happy to change though if this seems like a silly micro-optimization 🙂

[konstin]

There's some risk we break uv_build for existing packages, is there a way to check whether the classifiers in the wild (or their subset for uv_build projects) are valid? The risk is that this transitively affects packages that depend on the source dist of the package with the invalid classifier.

Code looks good otherwise.

[woodruffw]

is there a way to check whether the classifiers in the wild (or their subset for uv_build projects) are valid?

I could probably do a batch scan of PyPI, although I think PyPI has also validated classifiers on upload for a very long time so I wouldn't expect anything in the last 7+ years to have an invalid classifier in its metadata.

Still, I agree it's a risk. Do you think it makes sense to start with a warning here instead and then ratchet down in the next breaking release?

[konstin]

I could probably do a batch scan of PyPI, although I think PyPI has also validated classifiers on upload for a very long time so I wouldn't expect anything in the last 7+ years to have an invalid classifier in its metadata.

That's perfect then!