Deprecate update command

[jcrqr]

When I've introduced the gh releaser update command the idea behind it was to allow people to update the version of an open release on new changes pushed. After an offline discussion with a colleague we realized that this doesn't make sense because:

• When you open a release that introduce features or breaking changes you should have already bumped the MINOR or MAJOR versions, respectively. Since you can't (or shouldn't) push new features or breaking changes to a release candidate, no changes to the version should be expected
• When an open release only has bug fixes, you should have already bumped the PATCH version and even if you push more bug fixes to the release candidate, the PATCH version doesn't need to be bumped anymore. Same as above, no new features or breaking changes are expected to be pushed to the release candidate so we would never need to bump the MINOR nor MAJOR versions.

Considering the above points, I believe we should deprecate this command and don't support it anymore and, instead, advice people on the best practices for release management in projects that follow the git flow branching model.

Opinions are welcome.

cc @jsmvaldivia

[jsmvaldivia]

@crqra We can introduce the idea of creating release candidates first(tagging them accordingly) when using the opening command and then closing them on release close tagging them with a closed release version ready for production

[jcrqr]

That can be a bit out-of-scope for this tool. The original idea is to only manage the release process for gitflow projects on GitHub without making any assumptions or enforcing any version formats (like SemVer). That could be handled by tools like git-semver (no support for pre-releases yet) or commitizen - for when people want to use SemVer - or other tools for other versioning formats.