Adding GitLab support

What and why

I have noted that I am not alone wanting to do such thing (several issues and opened PRs, I think I have seen some more than 6 months old), and I guess it is not a high priority for the team, so I decided to make a small PR that does it, easy to review, basically maximally piggy-backing on gh code. It should thus be easy to maintain and review, since it is quite minimal.

An example of an issue: #6445.

The PR changes +345/−31 source lines (+330/−16 ignoring whitespace) and adds 112 test lines. An example of some open PRs, much harder to review: #7018 (actually currently broken from when I tested it) and the huge #8241 (an issue with several sub PRs ^^'), if you prefer it, obviously go for it :)

Done

For a workspace on a GitLab remote:

• Status: the sidebar and PR status show its MR (draft, open, merged, closed).
• Checks: each job of the head pipeline is a check.
• Review: "approved" or "review required".
• Actions: Create PR, Merge (merge, squash, rebase) and Ready for review run glab mr create|merge|update.

Design (optimizing for ease of coding and reviewing, lazy but not dirty)

• Detection: a remote is GitLab when glab knows its host (glab config get api_host --host <host>). That's a local read. A known host is remembered, so a refresh spawns nothing for it, and a host added later shows at the next refresh.
• No host settings in Superset: every call is glab … -R https://<host>/<path>, and glab maps SSH-alias and self-managed hosts itself. (Easy to do for edge case setups and the like, glab config only, any llm would do it in a giffy if someone has any issue...) => this makes the code much simpler obviously
• Identity: a GitLab owner is host/group (an HTTPS port is kept). MRs of two instances never collide, and Merge/Ready choose GitLab when the owner has a slash, which a GitHub login can't. => this makes the code much simpler obviously and is easy to understand for future coders :) it avoids quite a lot of useless complexity to handle
• Reuse: MRs map onto the existing PR shape, so caching, linking and storage are reused unchanged. Nothing is written to the project row.

Follow-up: #8724 adds MR discussions, CI job logs, the PR pane (content, diff, close/reopen) and creating a workspace from an MR. (again same mindset... easy to review, feel free to do it after this one... It looks bigger because it is on top of main obviously, if you merge this one it will be much smaller obviously)

How I tested it

I had a llm do lots of scenarios in a desktop dev build on a self-managed GitLab. Unit tests cover the linking, the remote parsing and the host detection; bun test in packages/host-service passes.

Checklist

• PR title follows conventional commits (type(scope): subject)
• bun run lint passes. bun run typecheck reports no errors in the changed files; the local desktop check fails on unrelated UI-library types.
• "Allow edits from maintainers" is checked on fork PRs