resource/gitlab_branch_protection: Allow to manage branch protection for default branch

This change to the gitlab_branch_protection resource will allow to protect the default branch of a project without importing. It basically works by unprotecting and protecting the default branch again in case it already exists when the resource is created. This allows the following code to properly work:

resource "gitlab_project" "example" {
    name = "example"
    initialize_with_readme = true
}

resource "gitlab_branch_protection" "default_branch" {
    project = gitlab_project.example.id
    branch = gitlab_project.example.default_branch

    // ... whatever settings ...
}

The drawback of this is that it quickly unprotects the default branch to protect it again in the above scenario. However, it already does that for pretty much any update to the resource attributes, because of the lack of a proper upstream update API. In addition, it's just a special case and maintenance effort - but I guess that's what docs are for and the suppose that the benefits for the users outweigh the maintenance burden.

If tried to implement something along the lines of https://github.com/gitlabhq/terraform-provider-gitlab/issues/792#issuecomment-1029148287 but it turns out it's harder to implement than expected.

The problems are:

• lack of diff / plan customization on the schema: https://discuss.hashicorp.com/t/ignore-the-order-of-a-complex-typed-list/42242
• when implementing the possibility to protect branches in the gitlab_project resource we'd also need to allow to share the projects with groups in add members in the resource, because those groups or users maybe used in the branch protection. There again, we need better plan / diff control then what the provider sdk provides us at the moment.
• it basically would mean an integration / duplication / re-use of the gitlab_project_share_group, gitlab_project_membership and gitlab_branch_protection in the gitlab_project resource. Which I guess would be okay with the proper implementation, but then again the currently proposed "solution" in this PR may be good enough.

Refs: #792 (closed) Closes: #671 (closed)

@PatrickRice-KSC @armsnyder @nagyv @ShockTrooper What are your thoughts here?