feat(commands): Add support for Range[LargeInt, ...]

[Enegg]

Summary

Closes #787
This PR adds support for defining a range of accepted values for commands.LargeInt.

If both bounds are specified, we restrict the length of the string input according to the number of digits (and sign) of the bounds.

We also raise an error during conversion, if the provided value would exceed the defined range (for example Range[LargeInt, 100, 200] would have actual possible input of 100-999).

I've also implemented a check in case the developer attempts to define a range exceeding ±2**53 with the normal int type, directing them to LargeInt.

Checklist

• If code changes were made, then they have been tested
  • I have updated the documentation to reflect the changes
  • I have formatted the code properly by running pdm lint
  • I have type-checked the code by running pdm pyright
• This PR fixes an issue
• 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, ...)

[DJStompZone]

[Enegg]

Tangentially related: we could add slice support for defining ranges (Range[int, 0:32], String[str, :10]). Not sure how useful it'd be.

[onerandomusername]

Hi, would you please resolve conflicts?

[read-the-docs-community]

Documentation build overview

📚 disnake | 🛠️ Build #30061266 | 📁 Comparing 57f7855 against latest (79a8027)

🔍 Preview build

Show files changed (48 files in total): 📝 48 modified | ➕ 0 added | ➖ 0 deleted

File	Status
index.html	📝 modified
whats_new.html	📝 modified
api/abc.html	📝 modified
api/activities.html	📝 modified
api/app_commands.html	📝 modified
api/app_info.html	📝 modified
api/audit_logs.html	📝 modified
api/automod.html	📝 modified
api/channels.html	📝 modified
api/clients.html	📝 modified
api/components.html	📝 modified
api/emoji.html	📝 modified
api/entitlements.html	📝 modified
api/events.html	📝 modified
api/exceptions.html	📝 modified
api/guild_scheduled_events.html	📝 modified
api/guilds.html	📝 modified
api/integrations.html	📝 modified
api/interactions.html	📝 modified
api/invites.html	📝 modified
api/localization.html	📝 modified
api/members.html	📝 modified
api/messages.html	📝 modified
api/misc.html	📝 modified
api/permissions.html	📝 modified
api/roles.html	📝 modified
api/skus.html	📝 modified
api/soundboard.html	📝 modified
api/stage_instances.html	📝 modified
api/stickers.html	📝 modified
api/subscriptions.html	📝 modified
api/ui.html	📝 modified
api/users.html	📝 modified
api/utilities.html	📝 modified
api/voice.html	📝 modified
api/webhooks.html	📝 modified
api/widgets.html	📝 modified
ext/tasks/index.html	📝 modified
ext/commands/api/app_commands.html	📝 modified
ext/commands/api/bots.html	📝 modified
ext/commands/api/checks.html	📝 modified
ext/commands/api/cogs.html	📝 modified
ext/commands/api/context.html	📝 modified
ext/commands/api/converters.html	📝 modified
ext/commands/api/exceptions.html	📝 modified
ext/commands/api/help_commands.html	📝 modified
ext/commands/api/misc.html	📝 modified
ext/commands/api/prefix_commands.html	📝 modified

[shiftinv]

Thoughts on adding a default= to this typevar? Otherwise pyright infers annotation.min_value as Unknown | None below.

[Enegg]

I took the liberty to instead move String/Range outside of TYPE_CHECKING, which allows pyright to actually typecheck their bodies, which in turn fixes the Unknown | None you mentioned.
Seems like this broke Sphinx though, would like some help resolving that :^)