MR Review: Introduce global MR cache

Problem to solve

When we submit a new comment on the diff, we need to calculate newLine and oldLine position. The trickiest scenario is when we comment on an unchanged line and we need to calculate the newLine and oldLine (#340 (closed)).

We currently can't get all information we need because there is a disconnect between the data available to the MrItemModel and the code diff

MrItemModel - we have all the API responses for MR, Discussions and MR Diff (version)
code diff (VS Code Diff view) - we have only the URI and what we can put into query parameter

When we create a new comment (new CommentThread) the only information available to us is the URI.

We need access to much more MR information when we create a new comment.

URI example

"gl-review:/src/commands/mr_discussion_commands.ts?%7B%22commit%22%3A%2265d828eb07558c8dfe03da797f6778fc18eece8b%22%2C%22workspacePath%22%3A%22%2FUsers%2Ftomas%2Fworkspace%2Ftest-projects%2Fgitlab-vscode-extension-TEST%22%2C%22projectId%22%3A5261717%7D"

The cryptical query string is encoded JSON:

{
    "commit": "65d828eb07558c8dfe03da797f6778fc18eece8b",
    "workspacePath": "/Users/tomas/workspace/test-projects/gitlab-vscode-extension-TEST",
    "projectId": 5261717
}

Why more information?

This is the full query to create a new note (notice the input):

mutation CreateDiffNoteNonChanged {
  createDiffNote(
    input: {
      noteableId: "gid://gitlab/MergeRequest/87196674"
      body: "new note"
      position: {
        baseSha: "5e6dffa282c5129aa67cd227a0429be21bfdaf80"
        headSha: "a2616e0fea06c8b5188e4064a76d623afbf97b0c"
        startSha: "5e6dffa282c5129aa67cd227a0429be21bfdaf80"
        paths: { oldPath: "test.js", newPath: "test.ts" }
        newLine: 8
        oldLine: 8
      }
    }
  ) {
    errors
  }
}

We could still put most of the information into the URL. The only information that would be missing is the lines.

Proposal

We can introduce a cache, through which we'll be able to retrieve all necessary MR information. Each MR is going to be uniquely identified by workspaceFolder (i.e. the local git repository) and mergeRequest.id the database numerical ID that is unique for GitLab instance.

The trickiest part of this cache is going to be designing the lifecycle of the cached MR (i.e. when will the cache get invalidated). Currently, we fetch all issues and MRs when the user triggers the GitLab: Refresh Sidebar command. (that would equal to cache invalidation).

Further details

Sketch of how this cache could look like is implemented in the POC (#293 (closed)) branch 293-new-comments-poc (MrRepository)