feat(GuildMember): Expose `serverMute` and `serverDeaf` fields

[RealAlphabet]

Please describe the changes this PR makes and why it should be merged: According to the developer documentation, it is possible to find out whether a member has been muted or deafen by right-clicking. Even if the member is not connected in a voice call.

This is documented by the presence of the two fields in the GuildMember structure.

Additional information: Unfortunately it's still not possible to mute or unmute a member if the member is not present in a voice channel. I intend to create an issue on discord-api-docs about this.

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

[vercel[bot]]

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

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
discord-js	⬜️ Ignored (Inspect)	Visit Preview		Aug 10, 2024 10:56am
discord-js-guide	⬜️ Ignored (Inspect)	Visit Preview		Aug 10, 2024 10:56am

[RealAlphabet]

1. the docs should state that this is about the server deaf/mute state (as opposed to personal mute/deaf, terminology in-client is "Server Muted"/"Server Deafened")
2. the current implementation always shows false for the inner payload of interactions, as those seem to not receive the two fields. potentially making the field nullable could work (same as you need to explicitly fetch a user to receive their public flags)l though this might also be an upstream bug

I've taken your suggestions on board. Thank you for taking the time to read my PR. I'd be grateful for feedback on the latest changes. I've taken the voiceStateUpdate event into account so that the voice state of a "previously disconnected" member reflects the two fields.

For your second point, it might definitely be an upstream bug. At least it should be documented by Discord.

[almostSouji]

Asking for clarification upstream: https://github.com/discord/discord-api-docs/issues/7125 Putting this on hold since this influences how we may want to implement the feature.