[Refactor] Flatten message passing layers

Description

After refactor: Move non-auth mediator commands to ipc (!295 - merged), there are 2 layers of message passing that happen now:

1. From the VSCode extension to the Iframe context. These are the "Mediator messages" (formerly "Mediator commands") and are dfined in packages/vscode-mediator-commands.
2. From the Iframe to the main runtime context (i.e. the @gitlab/web-ide entrypoint module). These are defined in packages/web-ide-types.

This is confusing and there's likely a lot we can do to create a SSOT for messages passed to/from different runtime contexts. We also probably don't need a separate "Mediator message" for every message that just posts back to the main runtime context.

Context

The following discussion from !295 (merged) should be addressed:

• @viktomas started a discussion:

  (non-blocking)(follow-up): Regarding the keys, I'd love to make the web-ide-types package the SSOT:

  export const START_REMOTE_MESSAGE_KEY = 'start-remote' as const;
  /**
   * Message sent to tell the parent window that we want to start a remote connection.
   */
  export interface StartRemoteMessage {
    key: typeof START_REMOTE_MESSAGE_KEY;
    params: {
      remoteHost: string;
      remotePath: string;
      connectionToken: string;
    };
  }

  We discussed how the messages pass two different contexts (VS Code -> Iframe -> Main), but we said they have the same format and can have the same keys and params.

• @viktomas started a discussion:

  (non-blocking)(follow-up): It would be really nice to make the path of the message more obvious in both the code and the documentation. I'd be happy to pair when you are less busy @pslaughter.

  If the messages always flow in the direction VS Code -> Iframe -> Main, we could have the components named based on the boundaries like:

  • VSCodeToIframeSender VSCodeToIframeReceiver
  • IframeToMainSender IframeToMainReceiver