Voice Rework -- Events, Track Queues (#806)

This implements a proof-of-concept for an improved audio frontend. The largest change is the introduction of events and event handling: both by time elapsed and by track events, such as ending or looping. Following on from this, the library now includes a basic, event-driven track queue system (which people seem to ask for unusually often). A new sample, `examples/13_voice_events`, demonstrates both the `TrackQueue` system and some basic events via the `~queue` and `~play_fade` commands.

Locks are removed from around the control of `Audio` objects, which should allow the backend to be moved to a more granular futures-based backend solution in a cleaner way.

src/events/core.rs

@@ -0,0 +1,31 @@
+#[derive(Clone, Copy, Debug, Eq, Hash, PartialEq)]
+/// Voice core events occur on receipt of
+/// voice packets and telemetry.
+///
+/// Core events persist while the `action` in [`EventData`]
+/// returns `None`.
+///
+/// [`EventData`]: struct.EventData.html
+pub enum CoreEvent {
+    /// Fired on receipt of a speaking state update from another host.
+    ///
+    /// Note: this will fire when a user starts speaking for the first time,
+    /// or changes their capabilities.
+    SpeakingStateUpdate,
+    /// Fires when a source starts speaking, or stops speaking
+    /// (*i.e.*, 5 consecutive silent frames).
+    SpeakingUpdate,
+    /// Fires on receipt of a voice packet from another stream in the voice call.
+    ///
+    /// As RTP packets do not map to Discord's notion of users, SSRCs must be mapped
+    /// back using the user IDs seen through client connection, disconnection,
+    /// or speaking state update.
+    VoicePacket,
+    /// Fires on receipt of an RTCP packet, containing various call stats
+    /// such as latency reports.
+    RtcpPacket,
+    /// Fires whenever a user connects to the same stream as the bot.
+    ClientConnect,
+    /// Fires whenever a user disconnects from the same stream as the bot.
+    ClientDisconnect,
+}