The reporter struct can be used for passing around and reporting to
the io.Writer of choice.

This allows gitlab-shell to be called with an argument of the format
`key-123` or `username-name`.

When called in this way, `gitlab-shell` will call the GitLab internal
API. If the API responds with user information, it will print a
welcome message including the username.

If the API responds with a successful but empty response, gitlab-shell
will print a welcome message for an anonymous user.

If the API response includes an error message in JSON, this message
will be printed to stderr.

If the API call fails, an error message including the status code will
be printed to stderr.

This adds parsing if the `secret_file` from YAML. And reads the
contents of the configured file.

If no file is configured, we fall back to the `.gitlab_shell_secret`
in the root dir of the configuration.

If the configured path does not start with a `/` we start looking for
the file relative to the root dir of the configuration.

Adds distributed tracing instrumentation to GitLab-Shell using LabKit

When SSH_CONNECTION is not set, we don't fall back to ruby, but
instead fail directly in go writing the error to stderr.

This adds the possibility to enable features for GitLab shell.

The first feature being recognized is "Discover": It's the command
that is executed when running `ssh git@gitlab.example.com` and is
called without a command.

The gitlab key id or username is already parsed from the command line
arguments.

Currently we only support communicating with GitLab-rails using unix
sockets. So features will not be enabled if the GitLab-url is using a
different protocol. The url for this read from the config yaml.

Pending ruby-specs have been added for the gitlab-shell command.

Refactor to have separate command packages