Implement support for rate limits from GitHub

[rickardl]

GitHub rate limits may apply to some actions when using the API, If we hit a rate limit, it's expected that we back off from making requests and try again later.

• When you have been limited, use the Retry-After response header to slow down. The value of the Retry-After header will always be an integer, representing the number of seconds you should wait before making requests again. For example, Retry-After: 30 means you should wait 30 seconds before sending more requests.
• Requests that create content which triggers notifications, such as issues, comments and pull requests, may be further limited and will not include a Retry-After header in the response. Please create this content at a reasonable pace to avoid further limiting.

[bgandon]

The GitHub documentation seems to have evolved a bit, introducing x-ratelimit-remaining and x-ratelimit-reset headers.
See: https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#handle-rate-limit-errors-appropriately

So the proposed implementation in #238 may have to evolve. But in my own experience, I've never hit rate limits with GitHub API—Is this issue still relevant?

Anyway, now that the Cloud Foundry community is maintaining a fork at cloudfoundry-community/github-pr-resource, it would be nice that any feedback is posted there. Thanks!