add support for string option bounds

[sebm253]

Pull Request Etiquette

• [x] I have checked the PRs for upcoming features/bug fixes.
• [x] I have read the contributing guidelines.

Changes

• [ ] Internal code
• [x] Library interface (affecting end-user code)
• [ ] Documentation
• [ ] Other: _____

Closes Issue: NaN

Description

this PR adds support for setting the minimum and maximum length for STRING options: https://github.com/discord/discord-api-docs/pull/5143

it's been a while since I touched JDA/Java so there may be things I forgot to add/change.

[MinnDevelopment]

Could we allow to use setRequiredRange for these as well?

https://github.com/DV8FromTheWorld/JDA/blob/master/src/main/java/net/dv8tion/jda/api/interactions/commands/build/OptionData.java#L559

[sebm253]

Could we allow to use setRequiredRange for these as well?

master/src/main/java/net/dv8tion/jda/api/interactions/commands/build/OptionData.java#L559

something like OptionData#setRequiredLengthRange?

[MinnDevelopment]

something like OptionData#setRequiredLengthRange?

no, just the same method with a conditional check for type.

[sebm253]

something like OptionData#setRequiredLengthRange?

no, just the same method with a conditional check for type.

I feel like that could be a bit confusing. introducing a new method would get rid of having to explain 2 behaviors of that method in the docs + long -> int conversions. making an overload which'd accept ints instead would probably confuse/annoy users as well - if they wanted to set the range for an integer option, they'd have to use Longs specifically otherwise it'd clash with the ints overload and throw, or am I misunderstanding here?

[MinnDevelopment]

I feel like that could be a bit confusing

I think it's more confusing for it not to work, which is why I'm suggesting it.

making an overload which'd accept ints instead

I don't think we need one?