add GitHub integration controller for projects (issue #289)

[mjtbdl]

Add GitHub integration controller for GitLab projects.

This adds a new IntegrationGithub managed resource that allows users to
manage GitLab's GitHub integration declaratively via Kubernetes. The
implementation follows the same pattern as the existing Mattermost integration.

New files:

• API types for IntegrationGithub
• Client functions (Get, Set, Delete, LateInitialize, IsUpToDate)
• Controller with Observe/Create/Update/Delete reconcile loop
• Tests for client functions and controller operations

Fixes #289

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

Unit tests added for all client helper functions and controller operations
(Observe, Create, Update, Delete). All tests pass with go test ./....

[henrysachs]

@mjtbdl thanks for the PR, this is a useful addition. I took another pass over the diff and the surrounding controller/client flow and I think there are still a few issues we should address before merge:

1. Finalization currently skips the actual remote delete
   Observe() returns ResourceExists: false as soon as meta.WasDeleted(cr) is true.
   In crossplane-runtime, Delete() is only called during finalization when observation.ResourceExists && policy.ShouldDelete().
   With the current logic, a deleted IntegrationGithub can lose its finalizer without ever calling DeleteGithubService(), so the GitLab integration may stay enabled remotely.

2. Token-only changes will never reconcile
   IsIntegrationGithubUpToDate() ignores token, which means rotating spec.forProvider.token does not make the resource out-of-date.
   Since the token is write-only and GitLab does not return it, this means token rotation is effectively a no-op unless some other compared field changes as well.

3. The new resource is not packaged yet
   I don’t see the generated package CRDs in this PR:

   • package/crds/projects.gitlab.m.crossplane.io_integrationgithubs.yaml
   • package/crds/projects.gitlab.crossplane.io_integrationgithubs.yaml

   Without those, the published provider package will not install the new IntegrationGithub resource at all.

4. The CRD currently allows specs that can only fail at reconcile time
   repositoryUrl is optional in the API, and an empty token still passes schema validation, but SetGithubService needs real setup inputs.
   So right now users can submit manifests Kubernetes accepts, while the controller can only fail later against the GitLab API.
   It would be better to enforce that in schema/validation, or at least reject it explicitly before making the API call.

EDIT: Furthermore ci is failing and you probably need to rebase because of the trivy github action.. sorry for that.