FIX(server, client): Fix ACL write and traverse permissions

[Hartmnt]

FIX(server): Make sure context is applied to traverse and write ACL

Previously, both the traverse and write ACL would be evaluatedwithout taking the "in this channel" and "in sub-channels" context options into account. This would lead to denying traverse for channels that were actually supposed to be traversable.

This commit refactors the ACL calculation for readability and makes sure the write and traverse checks are actually taking the context into account.

Fixes #3579

FIX(server, client): Remove "Write" ACL parent channel inheritance

Since 2a9dcfde4e423c4414f975a4b0b77cb08d08e782 and 62b1536fe0e91c03bf803075dff031a1f4dba9f4 the Mumble server would overwrite the current channel Write ACL, if the user had Write ACL permission in the parent channel. Supposedly, this was done because otherwise malicious users could create temporary "ungovernable" channels by locking admins out denying Write ACL for them. However, this makes ACL management a lot less intuitive with regard to the Write permission.

This commit reverts those commits and instead adds a check to see if the user has Write permission in the root channel instead. The reasoning being: If the server owner grants Write ACL on root, they probably want those users to be able to moderate every channel. If instead the server owner only grants Write on part of the channel tree, normal ACL rules apply and users may lock other users out for whatever reason.

FIX(client): Prevent unchecking both ACL context checkboxes

Previously, it was possible to have both context checkboxes disabled in the ACLEditor, leaving the ACL entry in a dangleing inactive state. This commit makes sure, that at least one of the checkboxes is always enabled.

[Hartmnt]

@Krzmbrzl Do you think backporting this is viable? I think it is and potential breakage is small.

[Hartmnt]

@Krzmbrzl gentle ping :)