[FEAT]: Add RequiredStatusChecks "checks" to github_branch_protection (GraphQL)

### Describe the need

## Problem Statement

The [github_branch_protection](https://registry.terraform.io/providers/integrations/github/latest/docs/resources/branch_protection#required-status-checks) resource uses the GraphQL API underneath and allows users to define required status checks via the `required_status_checks.contexts` field . This field is defined as a list of strings and does not allow specifying which GitHub APPs are responsible for reporting these status checks. GitHub automatically selects the APPs according to recent runs, but this isn't always desirable - especially in environments where 2 different apps may report the same status check or where workflows aren't run frequently.

The GitHub GraphQL API supports a richer configuration: a list of [RequiredStatusCheckInput](https://docs.github.com/en/graphql/reference/input-objects#requiredstatuscheckinput); which allows users to explicitly assign a GitHub APP to a status checks. However, the current Terraform resource schema does not have this field.

This issue is similar to the now closed issue #1212 where this feature was added for the [github_branch_protection_v3](https://registry.terraform.io/providers/integrations/github/latest/docs/resources/branch_protection_v3#required-status-checks) resource, which uses the REST API.

Although this issue was already resolved for the [github_branch_protection_v3](https://registry.terraform.io/providers/integrations/github/latest/docs/resources/branch_protection_v3#required-status-checks) resource, my use-case remains unresolved since this resource does not support wildcard patterns.

## Implementation Options

### Option A: New repeatable `check` block
Add a new repeatable `check` block under `required_status_checks`, allowing users to explicitly define both the context name and the GitHub App ID:
```hcl
resource "github_branch_protection" "example" {
repository_id = github_repository.example.node_id
pattern = "example*"

required_status_checks {
strict = true
check {
context = "foobar"
app_id = data.github_app.my_app.node_id
}
check {
context = "barfoo"
app_id = null
}
}
}
```

### Option B: New `checks` list

Mirror the approach used by github_branch_protection_v3 (see #1415), where the GitHub App ID is optionally encoded into each string element of a new `checks` list:
```hcl
resource "github_branch_protection" "example" {
repository_id = github_repository.example.node_id
pattern = "example*"

required_status_checks {
strict = true
checks = ["foobar:${data.github_app.my_app.node_id}", "barfoo"] {
}
}
```

## Open Questions

- How do we ensure mutual exclusivity between the new fields and the existing `contexts` field?
- The challenge lies in updating existing schemas without causing state drift due to the internal populating of the new field.
- Should the `contexts` field be fully deprecated?
- In this scenario, the schema version would be increased and a migration function would have to be written.
- Is backwards compatibility a requirement?
- Is parity with the REST API resource a requirement?

### SDK Version

_No response_

### API Version

_No response_

### Relevant log output

```shell

```

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct