maint: Updates go-github dep to v77

[nickfloyd]

Resolves: #2809, #2602 Relates to: #2898

This change set is large. This was an intentional decision to drive forward our need to update go-github given the current provider was 10 or more versions behind the latest. The hope is that the release will encapsulate all of the breaking changes over the last 12 months. This helps to make us just deal with them once if we choose to move forward on the major version bump. The last two releases were packed with much needed changes - so users, if they choose, can migrate as time allows while using the updates from v6.7.x and v6.8.x.

Additionally, we'll most likely cherry-pick out feature sets from this branch that are not actual fixes and the like - i.e. projects APIs have stopped working so we can look at projects v2 as a new feature.

---

Before the change?

• go-github v67

After the change?

• go-github v77

Checklist

• [x] Update go-github to >= v77
  • [x] Vendor / Mod
• ~[x] Convert/Replace projects to projects v2~ (#2898)
• [x] API renames edit > update
  • [x] resource_github_actions_organization_permissions.go
  • [x] resource_github_actions_repository_permissions.go
  • [x] resource_github_enterprise_actions_permissions.go
  • [x] resource_github_enterprise_actions_workflow_permissions.go
• [x] Fix CreateReference
• [x] Default Ruleset changes
  • [x] resource_github_organization_ruleset.go
  • [x] resource_github_repository_ruleset.go
  • [x] respository_rules_utils.go
• [x] Ensure test coverage and documentation (for new and deprecated)
• [x] Ensure schema migrations if needed
  • [x] RuleSet migrations

Pull request checklist

• [x] Schema migrations have been created if needed (example)
• [x] Tests for the changes have been added (for bug fixes / features)
• [x] 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!

• [x] Yes
• [ ] No

---

[stevehipwell]

@nickfloyd I've noticed that you've swapped out team ids for slugs to deal with the deprecated methods but that will break the provider for anyone using it at any serious scale. The fix here is to deprecate the team_id field and introduce a parallel team_slug field; the cost of using a single field for both is significant and I previously optimised it for ID as that's what the provider was using in the REST API.

See #2497.

[nickfloyd]

@stevehipwell Thanks for the heads up. I'll definitely pull that out... I am pulling things out of this change set that are orthogonal to the upgrade - I'll pull those out and just throw the changes away instead.

[stevehipwell]

@nickfloyd now that the provider is under maintenance I wouldn't be against adding the team_slug fields. I've got a few other team changes that are waiting on this PR.

[stevehipwell]

@nickfloyd is this ready for a review?

[nickfloyd]

@nickfloyd is this ready for a review?

Yes it is ❤️ . I'll need to sync the branch with #2902 once/if you approve my changes there.

[stevehipwell]

@nickfloyd I'll review this shortly.