During the refactoring, we had to disable one test that hid the MR
status bar item when there wasn't any project. This commit fixes the
scenario by checking whether a GitLab project can be fetched for the
current workspace and if not, we hide all the status bar items. This
also happens to fix the #71.

When there is no workspace folder, we will skip refreshing all together.
This scenario can occur when user didn't open a project, or they use
multi-root project and don't have a file open in the editor.

This was a great win. We already had to fetch the MR anyway in the
`refreshPipeline` method, this commit reduces the `fetchBranchMR` method
to a simple presentation layer, saving us one or more API calls.

We separate methods for fetching the MR and closing issue so we can
later significantly reduce the MR fetching method.

This is best demonstrated by the following snippet from this commit:

```diff
- this.fetchBranchMrAndClosingIssue();
+ await this.fetchBranchMR();
+ await this.fetchMRIssues();
```

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.

The current order is:
1. Pipeline
2. Closing issue
3. MR

But logically it must be a different order:

1. Pipeline - pipeline is the most common out of the three
2. MR - some branches have an MR
3. Closing issue - can only exist if there is an open MR

We introduced `asMock` helper that prevents us from having to always
type cast the mock with `as jest.Mock`.

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.

After implementing detached pipelines, this method is only used within
the gitlab_service module.

Prefer detached pipelines and only report normal branch pipeline when
there isn't any detached pipeline (MR pipeline).

We also change the logic to fetch MR and pipeline at the same time
because we need to know MR anyway to be able to get detached
pipeline.

Refactoring status_bar to use both pipeline and MR from the response
is too difficult to squeeze in this change. We'll have to do it later.

By relying on an exception, we are able to remove several checks
for failed project fetching. This also saves one extra call to
the /project endpoint. Additionally, this commit replaces a long
if statement with an early return.