Make rate-limiting configurable

[kfcampbell]

Fixes #845.

This PR provides a configurable delay to sleep between writes for our rate-limiting construct. Inspired by our very talented coworker Dave Cheney's "Functional options for friendly APIs" blog post. The default is the same as before, which is sleeping 1000ms between write operations.

Example terraform:

terraform {
  required_providers {
    github = {
      source = "integrations/github"
    }
  }
}

provider "github" {
  owner = "kfcampbell-terraform-provider"
  write_delay_ms = 50 # sleep for 50ms in between requests
}

resource "github_repository" "writedelay-test-repo-0" {
  name        = "writedelay-test-repo-0"
  visibility  = "private"
  description = "A test repository for looking at write delays."
}

Example log output showing new sleeping times:

2021-09-21T21:41:48.125-0700 [DEBUG] provider.terraform-provider-github: 2021/09/21 21:41:48 [DEBUG] Sleeping 50ms between write operations

Example error output when a negative value is given:

Example error output when a string is given:

Example error output when a cartoonishly large number (9999999999999999999999) is given:

---

@kfcampbell's TODO list:
Some things that need to be addressed before making ready for review:

• Validate that the integer is positive
• Is it desirable to give a default in both the schema and in the transport?
  • I think this is necessary.
• Manual testing
• Look into seeing if this is something we can test as part of an integration test
  • Existing transport_test.go tests don't test any of the behavior with write delays
  • I'm not quite sure how I'd go about adding this but I'm receptive to ideas if others have them.

[kfcampbell]

Questions for reviewers:

• Is write_delay an appropriate name? Should I use write_delay_ms or something else entirely?
• Are there ways of integration testing this behavior? There's no prior art.
  • Maybe we could do something where we invoke a timer and artificially make ourselves rate-limited? I'm not quite seeing how we'd do this.
  • Maybe it doesn't need it?
• Are there additional docs updates that are missing from this PR?

[jcudit]

This is on the right track. Added some cosmetic suggestions but likely to ship in the upcoming release.

[jcudit]

Excited to see this one land, thanks!