FEAT(client): Indicate talking users when locally muted

[Krzmbrzl]

Before this commit it is impossible to tell whether a client is talking
or not once that client is locally muted.

This commit changes this by introducing a new talking state
"MutedTalking" for these special cases. In order for this talking state
to come in existence, the audio code was altered so that audio packets
are no longer dropped if the associated user is locally muted. Instead
the audio frame will pass the normal processing chain until it comes to
actually decoding it.

For Opus packets only the sample count is read out without actually
doing the work of decoding. For all other codecs the packet is decoded
as usual. In a final step the sample buffer is filled/overwritten with
zeros in order to mute the stream.

With this commit in place, the UI will indicate a user that is talking
but is muted with a special icon. Note that this is only the case in the
modern themes (Light and Dark) but not for the Classic theme as I wasn't
able to alter the talking icon accordingly. There is an altered version
of the icon added with this commit but that one doesn't render properly
within Qt (it does render everywhere else though). Making this feature
work for the classic theme is a simple matter of getting the icon to
work and then editing ClassicTheme.qrc which currently points to the
same icon as for passive users for the MutedTalking state.

---

Screenshot:

[Krzmbrzl]

Note that this PR depends on mumble-voip/mumble-theme#29
Consequently the theme/Mumble submodule has to be updated once the theme-PR has been merged.

[streaps]

Do I understand it correctly that the full audio stream is transmitted just for a few bits of information (flashing icon)?

Edit: Never mind. I see this is a client only change and the audio stream was transmitted before too.

[Krzmbrzl]

Do I understand it correctly that the full audio stream is transmitted just for a few bits of information (flashing icon)?

Edit: Never mind. I see this is a client only change and the audio stream was transmitted before too.

Yes and yes.
In the future I'd much prefer to e.g. only send an indicator that that user is talking from the server to the client in these cases (which could be optional to be able to turn it off completely), but since the full audio stream is sent to the client anyways (at this point), we might as well use at least part of that information instead of discarding the stream completely 🤷