403 Forbidden Error on Projects with Pipelines Disabled

### Summary

When configuring the Gitlab Workflow Plugin with a repo that has Pipelines Disabled, the extension tosses a 403 when viewing Merge Requests. Enabling Pipelines allows Merge Requests to once again be polled and return results as expected. Gitlab in this bug report is self-hosted v13.4.2-ee and not on Gitlab.com (not sure if that matters).

### Steps to reproduce

*Note: this happens on `gitlab.com` as well.*

1. Setup on-prem (non-gitlab.com) personal access token
2. Setup Settings to use the proper Gitlab Instance URL (gitlab.examplecompany.com)
3. Find/Create a repository with Merge Requests Enabled and Pipelines Disabled.
    ![General___Settings___Tomas_Vik___test_project___GitLab](/uploads/425b823650eb8e1842a0a89269d10709/General___Settings___Tomas_Vik___test_project___GitLab.png)
4. Attempt to use the VSCode Plugin to view MRs but receive a 403
    ![Screenshot_2020-11-04_at_2.14.00_PM](/uploads/afadc494c8f938192e0af93ed6d59d62/Screenshot_2020-11-04_at_2.14.00_PM.png)

### What is the current *bug* behavior?

403 - Forbidden

### What is the expected *correct* behavior?

Ability to see Active/Closed MRs, or MRs assigned to "me"

### Relevant logs and/or screenshots

```
403 - "{\"message\":\"403 Forbidden\"}"
StatusCodeError: 403 - "{\"message\":\"403 Forbidden\"}"
	at new StatusCodeError (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/request-promise-core/lib/errors.js:32:15)
	at /Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/request-promise-core/lib/plumbing.js:97:41
	at tryCatcher (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/util.js:16:23)
	at Promise._settlePromiseFromHandler (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/promise.js:547:31)
	at Promise._settlePromise (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/promise.js:604:18)
	at Promise._settlePromiseCtx (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/promise.js:641:10)
	at _drainQueueStep (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/async.js:97:12)
	at _drainQueue (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/async.js:86:9)
	at Async._drainQueues (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/async.js:102:5)
	at Immediate.Async.drainQueues [as _onImmediate] (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/async.js:15:14)
	at processImmediate (internal/timers.js:439:21)
```

### Possible fixes

The fix for now is to enable Pipelines in the project settings.

The [offending code in `current_branch.js`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/a03468d9e525fa9c9835fa8466e48646b8369f18/src/data_providers/current_branch.js#L101-103):

```js
  async getChildren() {
    try {
      const workspaceFolder = await getCurrentWorkspaceFolder();
      this.project = await gitLabService.fetchCurrentProject(workspaceFolder);
      await this.fetchPipeline(workspaceFolder);
      await this.fetchMR(workspaceFolder);
      await this.fetchClosingIssue(workspaceFolder);
    } catch (e) {
      handleError(e);
      this.children.push(new ErrorItem());
    }

    return this.children;
  }
```

Since the fetching pipeline fails, the whole request fail. This code didn't consider that some of the calls could be still successful.

Story points: 1.0