Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

This will help determine the version of the binary particularly on Cloud
Native GitLab, where VERSION may not be shipped with the binaries.

Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

This would help catch race conditions such as
https://gitlab.com/gitlab-org/gitlab-shell/-/issues/450 before merge.

We had `gitlab-shell-authorized-keys-check` and
`gitlab-shell-authorized-principals-check` as symlinks to
`gitlab-shell` before.

We determine the `Command` and `CommandArgs` that we build based
on the `Name` of the `Executable`. We also use that to know which
fallback ruby executable should we fallback to. We use
`os.Executable()` to do that.

`os.Executable()` behaves differently depending on OS. It may
return the symlink or the target's name. That can result to a
buggy behavior.

The fix is to create binaries for each instead of using a symlink.
That way we don't need to rely on `os.Executable()` to get the name.
We pass the `Name` of the executable instead.

Rename the ruby scripts to have `-ruby` suffix and add a symlink
for both to `./gitlab-shell`. The executable name will be used to
determine how args will be parsed.

For now, we only parse the arguments for gitlab-shell commands. If
the executable is `gitlab-shell-authorized-keys-check` or
`gitlab-shell-authorized-principals-check`, it'll always fallback
to the ruby version.

Ruby specs test the ruby script, the fallback from go to ruby and
go implementation of both (still pending).