[FEAT]: Data source to resolve the current repository from the Actions environment

### Describe the need

When Terraform runs inside a GitHub Actions workflow, the runner already exposes the current repository via `GITHUB_REPOSITORY` (`owner/repo`), and the provider already sources `owner`/`token` from the environment (`GITHUB_OWNER`, `GITHUB_TOKEN`). However, there is no way to reference the *repository the workflow is running in* without declaring an input variable and wiring `TF_VAR_repository: ${{ github.event.repository.name }}` in the workflow.

Today the only env-only (no-variable) workaround is an `external` data source shelling out to read `$GITHUB_REPOSITORY` + `jq`, which is brittle. It would be valuable for the provider to resolve the current repository directly from the environment, mirroring how the provider already resolves `owner`.

Note that the existing `github_repository` data source requires `name` or `full_name` and errors otherwise ("one of full_name or name has to be provided"), so there is no env fallback available today.

**Possible approaches** (deferring the final shape to maintainers):

1. **Extend `github_repository`** — make `name`/`full_name` optional and, when both are omitted, fall back to `GITHUB_REPOSITORY`. Smallest surface-area change; reuses the existing data source.

```hcl
data "github_repository" "current" {} # name/full_name omitted -> $GITHUB_REPOSITORY
```

2. **New dedicated `github_repository_current` data source** — no required inputs; resolves the current repo from `GITHUB_REPOSITORY` and exposes the same attributes as `github_repository`. Clearest intent, explicit and discoverable.

```hcl
data "github_repository_current" "this" {}
output "name" { value = data.github_repository_current.this.name }
```

3. **New broader `github_context` data source** — exposes Actions context (`repository`, `owner`, `ref`, `sha`, ...) from the runner env, of which repository is one field.

```hcl
data "github_context" "this" {}
output "repo" { value = data.github_context.this.repository }
```

**Recommendation:** option 1 (extend the existing data source) is the least invasive, with option 2 (`github_repository_current`) as a clean explicit alternative if maintainers prefer not to overload `github_repository`.

### GitHub Installation Type

- [x] GitHub.com (Free, Pro, or Team)

### Relevant log output

_None._

### Code of Conduct

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

Start by examining the existing github_repository data source and the provider's current owner environment handling. Compare the proposed fallback and dedicated data source approaches, then confirm the selected design resolves GITHUB_REPOSITORY without an input while preserving the existing name/full_name behavior.

Written by the indexing model from the issue text.