Fix packet ordering

[tazz4843]

Right now there's some issues with the way Discord sends packets, and especially the SpeakingStateUpdate events. The SpeakingStateUpdate event is never fired on time, and inevitably ends up losing some data.

Theoretical workarounds:

• check if audio is empty: this might mean the end of this speaking has been reached (see https://docs.rs/songbird/latest/songbird/events/context_data/struct.VoiceData.html#structfield.audio)
• check for five packets that are silent (0xF8, 0xFF, 0xFE) to signal the end (see https://discord.com/developers/docs/topics/voice-connections#voice-data-interpolation)

[tazz4843]

From the developer of Songbird themselves, apparently the first option would work, with a few differences:

• audio packets will always be 3,840 bytes (240 samples), so checking for empty would not work
• a portion of the last packet's audio may be included in this packet's current audio, so every event dispatch should check (at least) the last two elements and see if they both equal zero before doing any action.

However we need to do some digging into the audio data format first to verify these ideas.