Support semi-unified versions as a release workflow

[Gankra]

I think cargo-dist will largely already Do The Right Thing for this workflow but we should test/document it properly.

This is a workflow @epage described, and is used by clap. Essentially it's the same as "all versions are bumped in lockstep" but you don't bother bumping a version for a library if it didn't change. This is something that would work perfectly for cargo-dist and many of the workspaces I use fully-unified versions in.

Here's what it would look like in cargo-dist:

Since everything in the workspace goes into cargo-dist, every git tag is definitely bumping the version of that crate. However, cargo-dist-schema is updated much less often, so currently we do a lot of "nothing changed" releases for no real reason other than having the versions exactly the same.

However we could instead just say: yeah cargo-dist 0.2.0 uses cargo-dist-schema 0.1.0, because nothing changed in the schema in that version jump. But if 0.3.0 does need a schema change (say a new field is added), then we cut 0.3.0 for both crates, skipping over 0.2.0 for cargo-dist-schema.

This is also a lot friendlier to people depending on the libraries, as version resolution will be less finicky. Note that cargo-release already will complain to us when we needlessly cut a new cargo-dist-schema, so there's tooling to help you select the new release. I need to look into the exact cargo-release config that works best for this.

Note however that cargo-dist will probably still have a few "useless" releases due to prerelease/bootstrapping shenanigans.

[ashleygwilliams]

i have been wondering about this workflow for axohtml - tbh i think it makes a lot of sense and preserves information about whether there was a change which feels like a positive (axohtml is 2 libs, one for macros which changes relatively infrequently)

[Gankra]

tentatively adding this to 0.1.0 as a nice-to-have