This fixes the version numbers in `km-config` which broke with #13854.
This also fixes opening the download page in `km-config` because that
uses a version number in the URL.
Fixes: #14031
Follow-up-of: #13854
Previously the builder scripts defined a readonly `VERSION` environment
variable for the Keyman version. That caused problems when another
(external) script tried to define a `VERSION` variable. We encountered
this problem when trying to move the TC build steps of a configuration
into a single script (#13399) when we tried to source `~/.nvm/nvm.sh`.
This change uses a Keyman specific prefix for the version variables and
renames `VERSION` → `KEYMAN_VERSION` etc. Unfortunately these variables
are used in a lot of places, so this turned out to be a bit of a yak
shave.
Test-bot: skip
On local builds we shouldn't upload errors to Sentry. The
`build-utils.sh` script sets the `UPLOAD_SENTRY` environment variable
for that purpose. Also, Sentry doesn't like having an empty string
as pkgversion (which should no longer happen with the rest of this
change, but...)
When running from source we set the environment to `local` when
reporting to Sentry. This change also adds the package version and
the tier as additional Sentry tags.
This is a follow-up of PR #4581.
This change modifies the reported version number for km-config:
if km-config is installed from a debian package, the package
version will be output as well, e.g.:
`km-config version 14.0.252-beta (package version 14.0.252-1+bionic1)`
Otherwise the output will be identical to before:
`km-config version 14.0.252-beta-local`.
This change also modifies the script that sets the version number so
that builds on Jenkins are now detected in addition to TC.
This fixes#4579.
As of 14.0, `resources/build/build-utils.sh` defines the build variables:
```
```
The go/linux links need an #.# version so this PR changes from __majorversion__ to __releaseversion__.
