Implement package candidate/published lifecycle

Give we're moving toward a scheme were packages are uploaded as candidates rather than published directly to the index (c.f. https://github.com/haskell/cabal/issues/3931) we need to make sure that candidates don't pile up.

The usual workflow:
1. upload package candidate
2. inspect package candidate preview on hackage
3. repeat 1./2. until satisfied with outcome
4. publish candidate (either by Web UI or by `cabal upload --publish`)
5. delete candidate (either by Web UI or by CLI tooling which isn't widespread)

Step 5. is just busy work and gets easily forgotten

We could either address this in `cabal` by having it delete the candidate when using `cabal upload --publish`, but that wouldn't address the WebUI code-path.

So instead we should enforce the following invariant server-side:
- **A package version shall never exist both as published and candidate.**

Or put differently, a package version shall only be in one of 3 states:
- non-existent (initial state; -> {candidate, _published(*)_})
- candidate (-> {non-existent, published, candidate})
- published (final state)

_(*) going straight from non-existent to published will be restricted in future for new package names (c.f. #481)_

Expressed operationally, this could mean:
- when a package is published and there exists a candidate, said candidate shall be auto-deleted
- uploading a candidate version for an already published package version shall be rejected