fix: restore adopt-existing behavior in github_issue_label create (regression in v6.13.0)

[aklinkert]

Resolves #3559

---

Before the change?

resource "github_issue_label" used to be idempotent on create: a single
resourceGithubIssueLabelCreateOrUpdate did a GET first and adopted (updated)
a label that already existed instead of creating it. PR #3342 (released in
v6.13.0) split that into context-aware Create and Update functions, and the
new Create calls client.Issues.CreateLabel(...) directly with no GET-first
existence check.

As a result, creating a label whose name already exists on the repository fails
the very first apply with 422 Validation Failed [already_exists]. This is a
common case, not an edge case: GitHub (and GHES) seed every new repository with
default labels (bug, documentation, duplicate, enhancement,
good first issue, help wanted, invalid, question, wontfix), so any
config that manages one of those names now breaks on first apply. The resource's
own docs still promise the "check if the label exists, then update, otherwise
create" behavior.

After the change?

resourceGithubIssueLabelCreate now restores the pre-6.13.0 adopt-existing
behavior, in the current context-aware CRUD style: it calls
client.Issues.GetLabel(ctx, owner, repo, name) first; if the label already
exists it issues an EditLabel (adopting/updating it), and if the GET returns
404 it falls through to CreateLabel exactly as today. Any non-404 error from
the GET is returned. diag.Diagnostics/context signatures and tflog logging
are kept consistent with the rest of the file.

An acceptance test (adopts a pre-existing label on create without error) is
added: it manages the default bug label on an auto_init repository and
asserts the apply succeeds and the label's color/description are updated.

Note: I was not able to exercise the acceptance-test suite here as it requires
live GitHub org credentials. Maintainers should run
TF_ACC=1 go test ./github -run TestAccGithubIssueLabel to confirm. gofmt,
go vet ./github, and go build ./... all pass.

Pull request checklist

• Schema migrations have been created if needed (example)
• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

[github-actions]

👋 Hi, and thank you for this contribution!

This repo is maintained by GitHub and community members on a best-effort basis. We'll get to this as soon as we can.

You can help us prioritize by joining the discussion on open issues and PRs, sharing details on the changes you need, and reviewing other contributions.

---

_{🤖 This is an automated message.}