Co-authored-by: Ash McKenzie <amckenzie@gitlab.com>

LogData also contains a new LogMetadata struct

Also rename to Metadata

While gitlab-shell currently has a major version of v14, the module path
it exposes is not using that major version like it is required by the Go
standard. This makes it impossible for dependents to import gitlab-shell
as a dependency without using a commit as version.

Fix this by changing the module path of gitlab-shell to instead be
`gitlab.com/gitlab-org/gitlab-shell/v14` and adjust all imports
accordingly.

Changelog: fixed

Previously, gitlab-shell did not pass a context through the application.
Correlation IDs were generated down the call stack instead of passed
around from the start execution.

This has several potential downsides:

1. It's easier for programming mistakes to be made in future that lead
to multiple correlation IDs being generated for a single request.
2. Correlation IDs cannot be passed in from upstream requests
3. Other advantages of context passing, such as distributed tracing is
not possible.

This commit changes the behavior:

1. Extract the correlation ID from the environment at the start of
the application.
2. If no correlation ID exists, generate a random one.
3. Pass the correlation ID to the GitLabNet API requests.

This change also enables other clients of GitLabNet (e.g. Gitaly) to
pass along the correlation ID in the internal API requests
(https://gitlab.com/gitlab-org/gitaly/-/issues/2725).

Fixes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/474

Other functions are still expecting for `CommandArgs` instead
of `Shell`. They should be expecting `commandargs.Shell` now
since it has been renamed.

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 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