[FEAT]: Resources to attach code security configurations to repositories and set org/enterprise defaults

### Describe the need

The `github_organization_security_configuration` and `github_enterprise_security_configuration` **resources** being added in #3284 (and the matching data sources tracked in #3505) manage/read the *configuration object only*. They do **not** cover the two remaining lifecycle operations needed to actually roll a configuration out:

1. **Attaching** a configuration to repositories.
2. **Setting** a configuration as the default for newly created repositories.

Today those are only doable via the REST API or `gh`, so a fully Terraform-managed org-wide rollout isn't possible even after #3284 + #3505 land. This proposes resources to close that gap.

### Proposed resources

Two resources per scope (org + enterprise), keeping each declarative and round-trippable:

- `github_organization_security_configuration_repositories` — binds a configuration to an explicit set of repositories.
- Inputs: `configuration_id` (required), `repository_ids` (required list).
- Read/refresh via `ListCodeSecurityConfigurationRepositories`; drift-detects add/remove.
- `github_organization_security_configuration_default` — sets the org's default for new repos.
- Inputs: `configuration_id` (required), `default_for_new_repos` (`all` | `none` | `private_and_internal` | `public`).
- `github_enterprise_security_configuration_repositories` / `github_enterprise_security_configuration_default` — enterprise equivalents.

**Design note — why explicit `repository_ids` rather than exposing the API's `scope` verb:** the attach endpoint's `scope=all` attaches only repositories that exist *at call time*; repositories created afterward are governed by the *default* setting, not by a prior `all` attach. Modeling attach as `scope=all` would therefore perpetually drift as new repos appear. An explicit `repository_ids` list round-trips cleanly against the list endpoint, and new-repo behavior is expressed through the separate `_default` resource. Open to modeling `scope` as an alternative/among-other input if maintainers prefer — flagging the drift tradeoff up front.

### SDK support

The wiring already exists in the vendored SDK (go-github v88), so this is a resource-authoring task, not an SDK gap:

- `OrganizationsService.AttachCodeSecurityConfigurationToRepositories(ctx, org, configurationID, scope, repoIDs)`
- `OrganizationsService.SetDefaultCodeSecurityConfiguration(ctx, org, configurationID, newReposParam)`
- `OrganizationsService.ListCodeSecurityConfigurationRepositories(...)` (read side)
- Identical `EnterpriseService` trio.

Underlying REST: `POST /orgs/{org}/code-security/configurations/{id}/attach`, `PUT /orgs/{org}/code-security/configurations/{id}/defaults`, `GET /orgs/{org}/code-security/configurations/{id}/repositories` (and `/enterprises/{enterprise}/...` equivalents).

### Notes

Tracking separately from #3284 to keep the resource PR focused, per the maintainer's preference (same rationale as #3505). Happy to open the PR once the configuration resources land. Relates to the broader ask in #2043.

### Code of Conduct

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

Start by reviewing the configuration resources in #3284 and the data sources tracked in #3505, then inspect the vendored go-github v88 organization and enterprise methods named in the issue. Done means the four proposed resources support repository attachment, drift detection, and default-for-new-repositories behavior for both scopes, with the REST operations round-tripping correctly.

Written by the indexing model from the issue text.