Copy Git's behavior for resuming/aborting a workflow

When you run this tool for the first time, when it generates a release spec template, if it can't open your editor, it'll just spit out the path to the file it made and quit. Then when you've edited the file, you can just re-run the tool and it'll read the file and resume the workflow.

The problem is that if the tool throws an error while it's executing the release spec, the release spec file will stick around. That's fine, but it means that if you run the tool again, it will attempt to resume the workflow instead of regenerating a fresh release spec. That doesn't always work right now, because some things may have already been applied — some versions of packages might have been updated already, or the release branch may have already been created, or something like that.

~Two things: 1) We plan on fixing this issue in #9, and 2)~ To get around this, we have a `--reset` option that lets you restart the entire workflow if that's what you want.

But it raises a question: is it expected that re-running the tool will resume the workflow? I'm not so sure. Git, for instance, will produce an error if you attempt to restart a merge or rebase or reapply a cherry-pick while you are resolving conflicts. If you want to start over, you can say `--abort`; if you want to resume, you can say `--continue`. This seems like a good workflow, and I think it would make sense to adopt this instead of a `--reset` option.

Start by tracing the CLI's existing --reset handling, release-spec file lifecycle, and workflow resume path. Compare that behavior with Git's explicit continue and abort model. Done means the workflow's restart and continuation states are explicit and covered for partially applied release operations.

Written by the indexing model from the issue text.