Add --dry-run option

[CAD97]

This would be useful for learning how the tool works without accidentally changing remote state. Go through all of the motions of the command, but revert any and all changes and print a list of what actions were taken.

[pksunkara]

I agree, unfortunately, it was a bit complex for me to add it as part of the first release.

[pksunkara]

The hard part here is git related actions.

[mathstuf]

I think just reporting "would run git …; further action may depend on its results" is sufficient there as a first pass.

[leighmcculloch]

Another issue is what to do with crates in the workspace that are dependent on each other. It is not possible to use the official cargo publish --dry-run command on a crate if that crate is dependent on another crate version that isn't yet published.

[leighmcculloch]

I experimented with adding dry run support to cargo workspaces, and I think I came up with this workflow that works, although it doesn't address that last issue I mentioned above. The change is here: #78.

@pksunkara In terms of git related actions, I made the dry run option disable git pushes. I left the other git operations enabled because it is somewhat blurry where the 'dry run' line should fall on what happens and what doesn't. It is useful for the commit and tag to be created so as to see what would have resulted during a dry run, but it could also be annoying that this happens. However, because those things have their own options it is always possible for someone to turn them off.

[leighmcculloch]

Note that change #78 doesn't support workspaces where crates are dependent on each other, since cargo publish requires all dependencies to have been published even during a dry run. I didn't see a way to address this at this time.

I think the only way might be to have cargo-workspaces embed a local registry and run a http server for it and have cargo publish to that local registry as a "dry run". This could potentially be an extension made after #78.