feat: Voice Channel Send Effects

[Jiralite]

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

• Document the Voice Channel Effect Send event discord/discord-api-docs#6025
• feat(Gateway): add VoiceChannelEffectSend event discord-api-types#739

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)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
discord-js	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 14, 2023 8:40pm
discord-js-guide	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 14, 2023 8:40pm

[vercel]

@Jiralite is attempting to deploy a commit to the discordjs Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

⚡️ Lighthouse report for the changes in this PR:

Category	Score
🟠 Performance	89
🟢 Accessibility	100
🟢 Best practices	100
🟢 SEO	100
🟠 PWA	70

Lighthouse ran on https://discord-js-git-fork-jiralite-feat-voice-effects-discordjs.vercel.app/

[jaw0r3k]

may you add channel getter?

[jaw0r3k]

also shouldn't it be an action, which handlers just handle
like every other event?

[Jiralite]

Probably not. Extending Base would mean this would (not publically) add _clone(), _patch(), and _update() to the class which are all irrelevant methods. In addition, valueOf() for this structure would return undefined as there is no id sent in voice channel effects.

[Jiralite]

may you add channel getter?

This seems to already be done.

[Jiralite]

also shouldn't it be an action, which handlers just handle like every other event?

discord.js/packages/discord.js/src/client/actions/Action.js

Lines 5 to 15 in b27c1d0

	/*
	ABOUT ACTIONS
	Actions are similar to WebSocket Packet Handlers, but since introducing
	the REST API methods, in order to prevent rewriting code to handle data,
	"actions" have been introduced. They're basically what Packet Handlers
	used to be but they're strictly for manipulating data and making sure
	that WebSocket events don't clash with REST methods.
	*/

My take on this is until there are any REST events that affect this event or we need to manually call this code, there is no need to add it. It is a very simple structure: receive a WebSocket event then emit it. Also, not every event has an action. So no, it shouldn't be an action.