feat: add GitLab support

[harshs-dyte]

Fixes #478

The code is functional and feature-complete as far as my manual testing goes.

I haven't added any GitLab specific tests, opting to let the common forge tests cover the API surface over the githubmock approach taken by github to supplement the tests in spr/spr_test.go. If it's desirable to have this also test things via a mock GitLab API, I can make the change.

Also available as a stack in harshs-dyte#1 if you prefer to review it there.

[harshs-dyte]

I've tested this a lot more and discovered that the CI paradigms between GitLab and GitHub might differ entirely too much for spr to cope. When spr tries to merge a stack by changing the target of the top MR/PR, (at least on my company's instance) GitLab will trigger a full CI re-run and invalidate existing approvals which makes the MR unmergeable. I've tried multiple hacky solutions around it that I've also pushed to this branch, but I think this might just not be viable.

[palves]

I've tested this a lot more and discovered that the CI paradigms between GitLab and GitHub might differ entirely too much for spr to cope. When spr tries to merge a stack by changing the target of the top MR/PR, (at least on my company's instance) GitLab will trigger a full CI re-run and invalidate existing approvals which makes the MR unmergeable. I've tried multiple hacky solutions around it that I've also pushed to this branch, but I think this might just not be viable.

Does that actually work on github.com? On my company's repos, github does the same, it drops approvals. I've wondered why the spr documentation doesn't say anything about this, and whether I'm missing some repo or branch setting that makes it work for everyone else. I'd be great if the spr documentation talked about this.

[harshs-dyte]

I've tested this a lot more and discovered that the CI paradigms between GitLab and GitHub might differ entirely too much for spr to cope. When spr tries to merge a stack by changing the target of the top MR/PR, (at least on my company's instance) GitLab will trigger a full CI re-run and invalidate existing approvals which makes the MR unmergeable. I've tried multiple hacky solutions around it that I've also pushed to this branch, but I think this might just not be viable.

Does that actually work on github.com? On my company's repos, github does the same, it drops approvals. I've wondered why the spr documentation doesn't say anything about this, and whether I'm missing some repo or branch setting that makes it work for everyone else. I'd be great if the spr documentation talked about this.

We had required approvals enabled on GitHub.com and spr served us quite well for the past 6 or so months.

[ejoffe]

I really admire the effort here! This is a huge change, and it is well designed and thought out.
Having said that I'm not sure we should land this if the merge logic can't work.
Maybe this is better fit for a fork of the repo?
If we do want to move forward with this, here are some notes:

Issues Found

Bugs / Correctness

1. File handle leak in readGlabCLIConfig (gitlab/gitlabclient/client.go):
   os.Open() is called but the file is never closed. Add defer f.Close().

2. Fragile commit-ID parsing in GitLab client:
   Uses strings.Split(line, ":")[1] without checking the slice length. A line that is
   exactly "commit-id:" with no value will panic with index out of range. Should use the
   same commitIDRegex pattern used elsewhere in this PR, or at minimum check len(parts) > 1.

3. Brittle 401 detection in check() helper:
   Uses strings.Contains(msg, "401") to detect auth errors. Any error message containing
   "401" (e.g., in a URL or unrelated number) would trigger the auth error path. Should check
   the actual HTTP status code from the *gitlab.Response object instead.

4. PullRequest.String() now takes ForgeInterface (forge/pullrequest.go):
   Having a data struct's display method depend on an interface implementation is unusual
   coupling. Consider passing the URL string directly or pre-computing it on the PullRequest
   struct.

Missing Tests

5. No GitLab-specific unit tests:
   The new 529-line gitlabclient package has zero tests. At minimum,
   matchMergeRequestStack, commit-ID parsing from MR commits, and the merge retry/auto-merge
   logic should be tested. The PR description acknowledges this and offers to add them — I'd
   recommend requiring at least the stack-matching and merge logic be tested.

Performance

6. N+1 API calls in GitLab GetInfo:
   After fetching MRs, separate API calls are made per-MR for approvals and per-MR for commits
   (two separate loops). For large stacks this adds significant latency. Consider parallelizing
   with goroutines.

7. No pagination in GitLab MR/member listing:
   ListProjectMergeRequests and ListAllProjectMembers are called without pagination options.
   For projects with many open MRs or members, results may be incomplete.

Naming Inconsistencies

8. LogGitHubCalls: The GitLab client checks c.config.User.LogGitHubCalls for logging —
   should be renamed to a forge-agnostic name like LogAPICalls.

9. fetchAndGetGitHubInfo in spr/spr.go: Method name still references GitHub.

10. githubmock variable in spr/spr_test.go: Should be forgeMock or clientMock.

11. Mock client lives in github/mockclient/: Since it now implements forge.ForgeInterface,
    it would be less confusing in a shared location.

Other Concerns

12. Go version bump to 1.24.0: This is a significant jump from 1.21. Verify all CI
    environments support this.

13. No compile-time interface checks: Neither client has
    var _ forge.ForgeInterface = (*client)(nil) to catch interface drift at compile time.

14. Draft MR uses title prefix: "Draft: " prefix rather than GitLab's native Draft
    field in CreateMergeRequestOptions. The native API field is more reliable.

15. os.Exit(-1) for auth errors: Non-standard exit code. Convention is positive integers.

16. Config migration rewrites .spr.yml silently: migrateRepoConfigKeys reformats the
    file through yaml.Marshal, which may reorder keys and strip comments. Users may be surprised
    to find their config file reformatted.

17. BuildPullRequestStack panics on invalid branch names: Inherited from the original code,
    but a panic() in a CLI tool could be replaced with a returned error.

[palves]

Does that actually work on github.com? On my company's repos, github does the same, it drops approvals. I've wondered why the spr documentation doesn't say anything about this, and whether I'm missing some repo or branch setting that makes it work for everyone else. I'd be great if the spr documentation talked about this.

We had required approvals enabled on GitHub.com and spr served us quite well for the past 6 or so months.

Thanks for the feedback. But, I thought that the losing approvals when the base changes was hardcoded on github.com. See https://github.com/orgs/community/discussions/57513 for example, where people complain about exactly this to github, stating that this makes stacked PRs not-so-useful. I would really like to find what knob one needs to tweak to make this work.

Edit: moved this to a new issue to avoid polluting this PR further:
#481