feat: configurable max wait time for ratelimits

[onerandomusername]

Summary

closes #449

This adds a max_ratelimit_wait kwarg to the client creation which will raise a RatelimitTooLong exception on any endpoint if the time to wait would be too long.

Checklist

• [x] If code changes were made, then they have been tested
  • [x] I have updated the documentation to reflect the changes
  • [x] I have formatted the code properly by running task lint
  • [x] I have type-checked the code by running task pyright
• [x] This PR fixes an issue
• [x] This PR adds something new (e.g. new method or parameters)
• [ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
• [ ] This PR is not a code change (e.g. documentation, README, ...)

[onerandomusername]

Postponing this to 2.6 to leave time for further testing

[onerandomusername]

This requires a lot more work, due to the http handling essentially being duplicated in webhook/async_.py

[shiftinv]

This requires a lot more work, due to the http handling essentially being duplicated in webhook/async_.py

From what I can tell, the purpose of this is to avoid exceptionally large ratelimits (emojis, stickers, member edits, ...), none of which are expected to occur in webhook requests. Only implementing this for the core http module seems perfectly fine.

[onerandomusername]

Deferred until a complete ratelimit refactor can be done.