Precedence of detailed_merge_status values

This issues is not about an actual bug but rather a little inconvenience in the behaviour of detailed_merge_status.

In the gitlab.nvim plugin we are using the client-go library to fetch the merge request info and then showing the detailed_merge_status to the user as the Status like this:

This creates a little inconvenience that when the MR has both the not_approved and need_rebase attributes the not_approved is takes precedence and the user may take action to elicit approvals from colleagues. When necessary approvals are granted, the need_rebase value will be shown and after rebasing, the approvals may be removed requiring another round of approvals that could have been avoided if the need_rebase populated the value of detailed_merge_status with higher priority than not_approved.