refactor: introduce project-centric data model

This MR introduces a new internal state representation. The implementation is behind feature flag which can be enabled by adding "gitlab.featureFlags": ["model-refactor"] to the VS Code settings.json.

With the FF enabled, we only show recognized GitLab projects in the TreeView:

The new model

The core idea behind this refactoring is:

1. the local Git repository can have an arbitrary number of remote URLs
2. the extension can have multiple accounts set up for the same instance. Each account might have a different view on a GitLab project (Multiple accounts are not yet supported, but they will be supported soon).
3. hence we'll do a cartesian product of all remote URLs and accounts on the given GitLab instance
4. Then, we'll try to fetch projects for each of these combinations and let the user decide which one they want to use

Example

Repository:

.
└── local-repository
    └── origin
        ├── fetchUrl: git@gitlab.com:gitlab-org/gitlab
        └── pushUrl: git@gitlab.com:viktomas/gitlab

Two accounts for gitlab.com A, and B.

We'll end up with 4 ExistingProjects

• gitlab-org/gitlab fetched by user A
• gitlab-org/gitlab fetched by user B
• viktomas/gitlab fetched by user A
• viktomas/gitlab fetched by user B

Then we'll let the user choose out of these four, so the extension can work with a single GitLab project for local-repository. This choice is not implemented in this MR.

It could also happen that the user B can't access viktomas/gitlab and then we would end up with:

• gitlab-org/gitlab fetched by user A
• gitlab-org/gitlab fetched by user B
• viktomas/gitlab fetched by user A

Related to #558 (closed)