fix: handle 404 gracefully on gitlab_branch_protection delete

What does this MR do and why?

Fixes #6852 (closed).

When GitLab returns 404 Not Found during a terraform destroy of a gitlab_branch_protection resource (e.g. the branch protection was already deleted out-of-band), the provider previously surfaced a hard error and left the resource stuck in Terraform state.

This change adds a 404 check in the Delete handler: if the API returns 404, the provider logs a debug message and returns without error — treating the resource as already gone. This is consistent with the pattern already used in the Read and Update handlers of the same resource.

MR acceptance checklist

• Followed the Contribution guidelines
• Acceptance test added (TestAccGitlabBranchProtection_deleteOutOfBand) covering the out-of-band deletion scenario
• Code follows existing patterns (api.Is404 helper, tflog.Debug for the warning)

Changes

internal/provider/resource_gitlab_branch_protection.go

In Delete, after calling UnprotectRepositoryBranches, check for a 404 response and return without error if found.

internal/provider/resource_gitlab_branch_protection_test.go

Added TestAccGitlabBranchProtection_deleteOutOfBand which:

1. Creates a branch protection via Terraform.
2. Deletes it out-of-band via the GitLab API in a PreConfig function.
3. Runs Destroy: true and verifies the destroy completes without error.