"release" config

cargo-dist should more fundamentally understand how you structure your releases/versions, and should potentially be in charge of updating/committing them. I don't know if this entails us absorbing/partnering with a specific tool, or writing our own. But cargo-dist covering its ears and trying to not care isn't sustainable.

## History And UX

It was an intentional design decision of cargo-dist to be "bring your own release process". We always avoided having an opinion on how to *cut* a release, other than: well you better use a vaguely reasonable git tag. We assume you've done all the prep, made your changelogs, made your version bumps, made the commits, and, most importantly, tagged your commit.

Then once you push your tagged commit, cargo-dist handles the rest.

I originally designed cargo-dist around using [cargo-release](https://github.com/crate-ci/cargo-release) as a sort of "front-end" for the release process, but, while I love cargo-release, this hasn't really taken off with our users as The Way To Do It.

I notably underestimated the amount of people who want their release process to involve actual PRs, instead of just a push. The popularity of things like [release-plz](https://github.com/MarcoIeni/release-plz) speaks to that. We're compatible with release-plz, so hey success story for "bring your own release process".

Still, one of the most common pieces of feedback we get is more or less "i just want a single tool that does this" -- whether that tool is cargo-dist itself, or a thing that wraps cargo-dist.

## Technical Limitations

On a more technical level, it's also just a recurring Problem for features that cargo-dist... doesn't actually understand your release process.

Notably the Extremely Obvious feature of "builtin cargo publish from ci" has remained unimplemented because it raises the looming problem of "wait so how do we know what libraries in your workspace should be getting published?". It is deeply bizarre a tool for cargo releases supports *homebrew* publishes more natively than *cargo* ones, but, well, that's where we are!

`pr-run-mode=plan` is also fundamentally broken with per-package releases (as opposed to unified workspace ones), because it needs to know how you structure your releases to do its job. If you had to tell cargo-dist "yes i do unified releases" or "yes i intend to individually release x/y/z", then this could be fixed.

## Existing Cracks

Already the "bring your own release" story has holes in it, as we've added random features to support user requests.

[create-release](https://opensource.axo.dev/cargo-dist/book/reference/config.html#create-release) tells cargo-dist that you are probably using some kind of "release drafting" workflow and it should assume a github release with the appropriate tag already exists.

[dispatch-releases](https://opensource.axo.dev/cargo-dist/book/reference/config.html#dispatch-releases) tells cargo-dist that instead of tag-pushes you want to use a github workflow_dispatch form (implicitly tagging at the end when the github release is created).

[tag-namespace](https://opensource.axo.dev/cargo-dist/book/reference/config.html#tag-namespace) tells cargo-dist that you use git tags for other unrelated things, and that it should ignore tags that don't match a pattern.

Start with the linked cargo-dist configuration documentation for create-release, dispatch-releases, and tag-namespace, then compare the release workflows described for cargo-release and release-plz. The issue needs a defined scope and decision about which release structures cargo-dist should understand; done would require an agreed design for configuration, versioning, and release ownership.

Written by the indexing model from the issue text.