Deafen and Undeafen members

[valzargaming]

Adds deafenMember and undeafenMember functionality to voice channels.

[mikield]

One interesting though that came to me in this PR:

Can we have a context-full resources?
What I mean that, it would be awesome to have something like $channel->members->deafen(ID) instead of calling $channel->deafenMember().

We can return another type of MembersRepostory for voice channels.
So VoiceChannel::memebrs can be VoiceMembersRepository where we can perform voice-specific actions on members.

[valzargaming]

These two functions just update the member's properties and send them back to Discord to overwrite them. You could get this same effect by calling $member->deafen = true and following up with $guild->members->save($member), so it could be argued (correctly so) that this PR is inappropriate to begin with, and the logic should be changed to merely update the property and leave it up to the user to decide when the part should be saved. This is the same way you'd rename a channel, update the property and save it to the guild's channel repository.

I know right now it seems like there's a missing feature here, but the reality is some functions like un/deafening members don't actually have API endpoints associated with them. While I agree that we do need a better way to access the functionality from out of this specific context, I don't think adding aliases or unnecessary calls to the PATCH endpoint is the way to go about it. I've been considering adding traits to the classes that specifically handle updating parts to prep them for saving, but nothing is set in stone yet as I'm not sure how we would futureproof it.

[valzargaming]

I'm open for any suggestions on how to accomplish this. Looking things through some more I still think it makes more sense to scrap this PR completely.

Ideally a helper method should be made that would return a PromiseInterface so it can reject on a permissions error and resolve($this) on success. We'd need to set up something like setDeafAttribute, but the biggest roadblock is that the current implementation is hijacking the __set magic method which only allows for a void return... That brings us back to my original idea, creating new functions with PromiseInterface returns, and the original problem. I'm leaning towards something like ->setDeaf($bool): PromiseInterface and it matches code patterns already found elsewhere, such as $channel->setPermissions(): PromiseInterface, but it would lose the context needed to check for channel permissions.

The current best solution is to leave things as is. Developers will need to manually update the attributes and call $repository->save($part) where it's appropriate to do so.

[valzargaming]

The docs are surprisingly scarce as to how un/deafening and un/muting should work. For deafening, the only requirements are the bot having the DEAFEN_MEMBERS bitwise permission and for the member to currently be in a voice channel, necessitating the need to call the function within the context of a channel. Muting members is identical except that the bot is allowed to mute itself. The only way we're able to implement this properly at this time is with the original suggestion, else the Member part would need to accept a channel as a parameter, which could cause further confusion as it'd be possible to pass a channel the member isn't already in, and would break the library's patterns.

[valzargaming]

This should be production ready now