Use "v" prefix in zeebe versions

[MiguelPires]

Description

Zeebe uses semver without a leading "v" which, unfortunately, Go modules expect. The result is that gomod turns a version like "0.23.0" into a pseudo-version which looks like "v0.0.0-20200703113403-f8f0e0399f70". This is not very readable for users and makes managing versions difficult. To be clear, specifying a version like "0.23.3" will point to the correct client version but the go.mod file will be edited by Go modules to change it to a pseudo-version. To get a glimpse into a user's perspective, see what this user reported https://zeebe-io.slack.com/archives/C6WGNHV2A/p1596482952444700. Essentially, it makes it difficult for a user to know what his Zeebe version is (unless he remembers what he set originally) and he can't downgrade to an earlier version since it's not clear what that is. Note also how our versions look like in the official documentation portal https://pkg.go.dev/github.com/zeebe-io/zeebe/clients/go/pkg/zbc?tab=versions. I think this will also be an issue when we release different major versions since I'm not sure if Go would be able to tell if two version are compatible or not.

It seems like there's no concrete plans to address this in the Go tooling. I think it'd introduce some issues for them (like are vx.y.z and x.y.z the same thing?) so we shouldn't expect the issue to resolve itself. Relevant issues: golang/go#30146 (closed) golang/go#32945 (still active)

To address this we can have version tags with and without a leading "v", in order to not break anything that might expect one particular format.

Edit: found this section of the docs https://github.com/golang/go/wiki/Modules#modules that explicitly states that the leading "v" is required

[MiguelPires]

I tried this out in our Go getting started guide by refactoring it to use go modules (I also wrote a script to automatically update and test the guide) and it worked. So we can solve the aforementioned problem for our go client users by having an additional tag per release. One important and not-so-obvious detail is that the tags must have a "clients/go" prefix so that go modules can find them (e.g., clients/go/v0.24.1). This is because we use submodules in our repo. The path of our Go module is "zeebe-io/zeebe/clients/go" and not "zeebe-io/zeebe" where the tags can be found, so we must use this mechanism to deal with that. Here's a sample repo that uses this (look at the tags) and some documentation:
https://github.com/go-modules-by-example/submodules
https://github.com/go-modules-by-example/index/blob/master/009_submodules/README.md