This fixes a minor bug where if user hasn't configured their
instaenceUrl (presumably they use the default gitlab.com),
the webview is going to put `null` in the links. This fix
makes sure we use the same logic as the rest of the app.

Extracting configuration related logic came up in reviews multiple times.
Also, the VS Code logic returns missing properties as null.
This behaviour is not ideal because null function arguments overrdie the
default function arguments.

Related discussions:
- !115 (comment 432956679)

The service can be made simpler by moving the pipeline specific remote
out of the service and exposing a more general method.

The `pipelineGitRemoteName` setting is used to say:
"Use this remote for getting pipelines"
This purpose of this configuration is to mark a fork. Then
you can read issues and MRs from the main project and
pipelines from your fork.

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.

This reduces the need for readers to keep a variable
in their head to read 50 LOC.

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.

All the data we need are in the API response that lists pipelines.

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

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

feat: suport detached pipelines

See merge request !186