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

Instead of using workspaces, we now use the repositories from
VS Code git extension to look for which projects should we show in
the sidepanel

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.

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.