feat: Updated repo collaborators to support ignoring teams

[stevehipwell]

Resolves #2470

---

Before the change?

• Using a team slug for github_repository_collaborators would result in churn
• There is no way to manage repository collaborators for an organization that has organization roles defined without specifying these teams as part of the github_repository_collaborators resource (which works but is technically incorrect).

After the change?

• Using a team slug for github_repository_collaborators does not churn
• You can use the team_ignore block on a github_repository_collaborators resource to ignore organization managed teams.
  • Due to the lack of flag in the GitHub API this can't be cheaply powered by a ignore_org_teams resource flag, as that would take multiple API calls and an increase in required permissions.

Pull request checklist

• 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

---

[stevehipwell]

@kfcampbell as this has been approved could you merge it?

[kfcampbell]

@stevehipwell Apologies for all the delays here and thank you as ever for your contributions. What's going on is that @nickfloyd and I have been pulled into some work for GitHub's broader extensibility future (which is fun! and it's going to be better for GitHub's SDKs in the long term!) but it means 100% of our time right now is being spent on internal projects. This is rough for SDKs support and it makes me feel bad because I want to do better for SDKs like the Terraform provider (you should see my GitHub notifications right now; the badge that counts the number went so high it's broken and simply reads 1). We've been trying to do a little bit with reviews and releases as we can snatch time here and there, but in general it's been impossible to find a balance that makes everybody feel good.

In the meantime, I'll keep trying to do a few PRs and a release every so often.

[JCY-Alchemy]

Thank you for addressing this. I just made myself a ticket to unlock our provider version and take this for a test drive. Thanks again.

[stevehipwell]

@kfcampbell could you maybe add what you wrote above to the #1342 discussion?

I understand that high level improvements will benefit us in the future but that's not helping us with today and the issue that are currently impacting us. I suspect that most of us non-GitHub contributors are doing this in addition to our actual day jobs and not having our PRs reviewed in a timely manner means we're both losing time on the broken or missing GitHub functionality as well as the time we've spent trying to make it better.

With that said I think that #2476 should make your ad-hoc reviewing significantly easier as the whole test suite actually works (locally) and passes (t also gracefully degrades to support the test inputs provided). But to get that merged there are a number of bug fix PRs I've linked in the description that need to be merged first, once these are merged I can rebase the PR and update any changed tests. Once #2476 is merged and the tests can be reliably run locally we could look at #2511 to run the tests in an automated way.