Add a caveat that restricts a project-scoped token to a specific release version

[woodruffw]

Right now, we have two caveats that restrict API tokens in the context of projects: ProjectName and ProjectID. The former is the only one that's strictly necessary; we use the latter to improve the error message in the (unlikely) event that a user has deleted a project, someone else has taken over the name, and the now-unprivileged user attempts to use their old scoped token.

In addition to these caveats, it would be nice to have a ProjectVersion or similar caveat that restricts which release can be uploaded to. This could be either an extant release or a new one; the idea would be to prevent token compromise from having an effect beyond a singular release (which the rightful owners/admins could then yank).

To do this, we'd need to somehow plumb the uploaded file's version into the caveats layer. That'll probably require some design thought.

H/T to @alex (secretly @reaperhulk) again 🙂

[woodruffw]

Triaging: I believe this is now mostly obviated by trusted publishing.

[dstufft]

I think it's still a reasonable ask? trusted publishing reduces the chances that a key can get leaked, and the length of time that a key is valid for, but it's still effectively a token that can be used to release for any version, and if someone gets their hand on it, it can do more than expected.

Plus I don't think we'll ever get to a world where everyone releases via TP.