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.

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

This reverts merge request !257

Fix two regressions in my 2e8b670 ("Add support for SSH certificate
authentication", 2018-06-14) merged in gitlab-org/gitlab-shell!207.

This fixes the issue noted in gitlab-org/gitlab-shell#145 where the
command-line contains things other than the key/user/username, and
also a regression where SSH certificates are being used, and the
username presented in the key is unknown to GitLab.

In that case, we should log the user in as "Anonymous" (on an instance
that allows public access), but because of how the error checking
around api.discover() was implemented we ended up erroring out
instead.