Improve rebasing experience

[jakubbortlik]

Feature Description

Currently, the information that a feature branch needs to be rebased (with fast-forward merge strategy) is only shown in the MR summary after the MR has been approved (before that, the summary shows not_approved. But sometimes, after rebasing, the approvals are removed and another round of approvals is required.

To streamline the workflow, it would be useful to show in the MR summary if the MR needs rebasing. However, I'm not sure this is possible at the moment. I've looked at the go-gitlab library and haven't found anything in the INFO that could be used to get this kind of detailed information - the DetailedMergeStatus only contains one string and unfortunately, not_approved seems to take precedence over needs_rebase.

Ideally, rebasing should be possible from the gitlab.nvim plugin, the go library supports this, and I think it would be a nice first issue.

[jakubbortlik]

I just noticed that I've created a partial duplicate of this in #508. But that issue only covers the first part of this one - the clearer indication of needs_rebase in the MR summary.

This feature request is therefore more about the second part - adding a command gitlab.rebase() which would rebase the source branch of the MR on top of the target branch and pull the rebased source branch from remote. This is only available in the new client-go library and if I understand correctly, it only affects the source branch on remote, that's why it's necessary to afterward pull the source branch (at least this is how the glab mr rebase CLI command works.

Rebasing locally and force-pushing the source branch can reset all approvals while rebasing over the UI is smarter about that and only resets approvals if the rebase affected the code included in the present MR. I assume, that using the API through the client-go library will also use this improved rebasing process.