Credit: [@Musisimaru](https://gitlab.com/Musisimaru) (originally
    introduced in
    [!229](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/229))

This is a copy paste of the code contributed by Mussimaru in
https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/229
This code doesn't compile, but I wanted to include it as a record that
he's done most of the work.

Credit: [@Musisimaru](https://gitlab.com/Musisimaru) (originally
introduced in
[!229](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/229))

When we create new diff threads, the API requires us to submit all three
values (start/base/head SHA) so even though we don't need startSha
internally, we have to parse it from the response.

This commit changes the way WrappedRepository exposes the
GitLabNewService. We used getter which was very hard to mock in tests.
Instead, we now use regular function (getGitLabService()) which is
easily replaced in tests.

Additionally, this commit creates a helper function for creating
WrappedRepository, because it is going to be used in many tests in the
future.

This commit replaces the GitLabRepository(GitLabWorkspace) interface
with the Wrapped repository. The original objects `{ label, uri, error}`
were constructed by the issuable.ts.

We now use the WrappedRepository and the error state is signaled by a
new `containsGitLabProject` boolean flag. I.e. if the wrapped repository
doesn't contain GitLab project, there has been error during fetching it.

Also having access to the wrapped repository from within mr_item_model
is going to be important in the next commit because it allows us to
interact with the MR cache.

We parse the MR version REST API response into hunks. These hunks tell
us what lines have been added in the new file version on the diff.
We then convert these lines in VS Code Ranges and return them as ranges
on which the user might leave a comment.

Instead of registering a new command, which was basically a callback, we
can declare what the item is supposed to do instead, reducing the amount
of procedural code.

Instead of triggering always one command which will decide what to do,
we can decide what to do at the time when we change the status bar item.

Instead of registering a new command, which was basically a callback, we
can declare what the item is supposed to do instead, reducing the amount
of procedural code.

Instead of triggering always one command which will decide what to do,
we can decide what to do at the time when we change the status bar item.

This prevents confusion between GitLab project and VS Code workspace.
The current legacy naming that uses the name "project" to represent
VS Code workspace is diverging from an established naming and
confuses contributors.

The work "project" is used throughout the codebase for GitLab project
and it was causing confusion when two variables named 'project' meant
different things.

We had to change the command for openning pipeline in the browser
to support detached pipelines.

This change starts fetching position for each discussion and then
it displays the discussions on diffs using the native VS Code API