GitLab integration: receive webhooks for automatic state sync

[emyller]

Context: #7000

When a linked GitLab issue or MR changes state (closed, merged, reopened), Flagsmith should update the feature flag's tags automatically.

Scope

• Expose a webhook endpoint for GitLab to call.
• Register project webhooks programmatically via the GitLab API when a resource is linked.
• Subscribe to issues_events and merge_requests_events.
• Webhook secrets should be generated by Flagsmith and stored on the configuration model, not provided by the user. The secret is created when Flagsmith registers the webhook via the GitLab API, and used to validate incoming payloads.

Tags

The following tags mirror the GitHub integration's tagging behaviour, adapted for GitLab terminology.

GitLab event	Tag
Issue opened / reopened	Issue Open
Issue closed	Issue Closed
MR opened / reopened	MR Open
MR closed	MR Closed
MR merged	MR Merged
MR converted to draft	MR Draft

Suggested implementation

• Add TagType.GITLAB; follow the GitHub tagging pattern.
• New model to track registered webhooks: GitLab project path, webhook ID, and secret per GitLabConfiguration.
• Expose a webhook receiver endpoint. Include the webhook tracking model's ID in the URL so the receiver can look up the secret directly.
• Verify incoming payloads via X-Gitlab-Token.
• Register a project webhook when a resource is first linked from a given GitLab project, using the URL-encoded path extracted from the resource URL.
• Deregister webhooks on GitLabConfiguration deletion.

Acceptance criteria

• Webhooks are registered automatically — the user does not configure them manually in GitLab
• Issue state changes in GitLab update the linked feature flag's tags in Flagsmith
• MR state changes (opened, merged, closed, drafted) update the linked feature flag's tags in Flagsmith
• Emit structlog events for product telemetry (Epic: Open structured event pipeline for the backend #7012)