feat(TypeGuards): add TypeGuards utility for commonly used data types

[suneettipirneni]

Please describe the changes this PR makes and why it should be merged:

Allows for easier type narrowing, for example:

function consumeOption(option: ApplicationCommandOptionData) {
   if (TypeGuards.optionDataSupportsChoices(option)) {
     // Has an `options` field.
     option.choices.forEach( ... )
   } else {
     // Doesn't have an `options` field.
   }
}

Closes #6409

Status and versioning classification:

• Code changes have been tested against the Discord API, or there are no code changes
• I know how to update typings and have done so, or typings don't need updating
• This PR changes the library's interface (methods or parameters added)

[vladfrangu]

I don't know if this is needed, since TS can infer from the properties if we have done unions right, but LGTM

[suneettipirneni]

I don't know if this is needed, since TS can infer from the properties if we have done unions right, but LGTM

You're correct, but I find doing having to do command.type === 'CHAT_INPUT' && command.type === Constants.ApplicationCommandTypes.CHAT_INPUT, is too verbose, and somewhat confusing. The TypeGuards in this context are more like aliases for these checks.

An alternative would be to split up the interfaces even more (add another interface for each variant, one for strings one for enums). But I dunno how I feel about that either.

[suneettipirneni]

On reevaluation it seems that command.type === 'TYPE' does work as intended without checking enum values, so I'll remove the command checks but keep the option/choice checking as those are still useful.

[iCrawl]

I think something like this might be better suited for @discordjs/typeguards or something, unsure about having this in the main lib.

[suneettipirneni]

That's fine by me. Should I close this now and wait for that repo to be published?

[iCrawl]

Our modules are usually in the https://github.com/discordjs/discord.js-modules repo.

You could theoretically look at the REST module and branch out your own if you wanted to in a PR. All we require is it having tests and the structure you can see how REST is built.

[suneettipirneni]

Sweet! I'll take a look