feat(projects): manage merge request approval configuration on Project

[alexandre-allard]

Description of your changes

GitLab exposes project-level merge request approval settings (reset-on-push, author/committer self-approval, reauthentication, etc.) through a dedicated /projects/:id/approvals endpoint that is separate from the main project update API.
This adds an optional approvals block on the existing Project resource, following the same pattern as pushRules, rather than introducing a separate CRD, since these settings have no independent identity or lifecycle apart from the project they belong to.

Fields are only reconciled when approvals is set in the spec, so existing Project resources are unaffected.

approvalsBeforeMerge is intentionally left out of the new approvals block, it's already managed via the existing top-level
ProjectParameters.approvalsBeforeMerge field (a different GitLab API), and duplicating it here would create two reconciliation paths for the same underlying setting.

Note on design:
I went back and forth on whether this should be a separate CRD (similar to the existing ApprovalRule resource) instead of a field on Project.
I ended up embedding it because these settings have no identity or lifecycle independent of the project they belong to, but I'm not fully set on this, so happy to split it out into its own resource if maintainers prefer that instead.

I have:

• Read and followed Crossplane's [contribution process].
• Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

Tested it on one of our clusters with real data and we're currently using it in production.

[henrysachs]

@alexandre-allard Thanks for this contribution. The embedded approvals block and separate endpoint approach look appropriate and consistent with pushRules.

One behavior should be clarified before merging. The API comments and example currently say that fields left unset inside approvals are not managed. In practice, lateInitializeApprovals fills all omitted fields from GitLab, Crossplane persists them, and subsequent reconciliation manages the complete block. This is consistent with the existing pushRules behavior, so I suggest keeping the implementation and updating the API comments, generated CRDs, and example to explain that setting approvals opts into managing the complete approval configuration, with omitted fields late-initialized from GitLab.

Codecov is also failing, but its baseline appears stale: it compares against c8311da from June 2024 with only 43 covered files, while this run includes 200 files. It consequently reports 48.48% (-10.55%) and 0% patch coverage despite the added tests. This may require a fresh coverage upload from master or a Codecov configuration fix rather than additional tests in this PR.

Separately, approvals are applied only through Update, like pushRules. Therefore managementPolicies: [Observe, Create] will create the project but not configure approvals. Since this is existing behavior for nested project endpoints, I do not consider it a blocker for this PR, but it may be worth documenting or addressing consistently later.