Adapt OAuth2 client to work when Web IDE is hosted on a separate domain

MRs:

• feat: cross-origin-channel package (!396 - merged)
• Authentication Provider based on cross-origin-c... (!397 - merged)

Description

The Web IDE OAuth-client is implemented under the assumption that Web IDE and the GitLab rails application co-exist in the same origin therefore they share the web browser's local storage. The OAuth-client uses the web browser's local storage to share OAuth access tokens between GitLab rails and the Web IDE. In a scenario where the Web IDE and the GitLab instance have different origins, this assumption is broken and the OAuth-client won't work anymore.

Instead of relying on the Web Browser's local storage to share OAuth access tokens between the GitLab instance and the Web IDE, we can rely on a message channel. The OAuth client handles the OAuth authentication flow in the GitLab instance origin and keeps the OAuth access token stored in that origin. The GitLab instance creates a message channel and passes one the channel's ports to the Web IDE via iframe's postMessage method. The GitLab rails application can still store the access tokens in the Web browser's local storage to share state between tabs, but it should pass the OAuth access tokens to the Web IDE via the message channel port.

The following diagram attempts to illustrate how both origins communicate via a MessageChannel.

Acceptance Criteria

• Transfer OAuth access tokens between the GitLab instance's origin and the Web IDE's origin via a MessageChannel.
• Move cleanExtensions call from the gitlab-web-ide package to the vscode-bootstrap package.