Revisit grouped edit buttons to distinguish between Web IDE and other editing flows

Problem to solve

As the new Web IDE becomes more capable of handling complex development tasks, we should revisit the contexts in which it is launched from the GitLab UI to make sure it's clear what the use cases are for each editing experience.

Currently, the CTA for opening the Web IDE is different depending on whether you are at the root level of a project, a file in a repository, or an MR.

Project root	File	MR

Additionally, we have a Gitpod integration and potential avenues for additional integrations that could introduce more platforms or contexts in which the file/repo is opened.

Background

We worked hard in the past to consolidate these buttons and have seen a dramatic uptick in Web IDE usage since rolling it out. We would risk erasing all that success if we backpedal on that pattern. But does it make sense still?

Proposal

Since the MR introduced a groped Code button, what if we followed that pattern in all three contexts?

At the project root, we'd need to understand whether to combine Open in and Clone buttons into a single, über button. Or have two separate buttons Open in... and Clone

Bonus: I think having an Open in... button conforms better to our Pajamas guidelines for grouped buttons.

Goal

Understand whether moving back to a pattern where the Edit action on a single file is entirely separate from the concept of Opening in the Web IDE