API improvement: consider a split() function

[bschwind]

Similar to how tokio's TCP stream has a split function to give read and write halves, it would be nice to have the same for the audio processor, where split() would give you a CaptureProcessor and a RenderProcessor. This could make the API a little easier to use when you're not using a duplex audio stream, as then you wouldn't need to put the processor in an Arc<Mutex<_>>

[skywhale]

You don't need Arc<Mutex<_>> because the processor is internally thread-safe. Right now, you clone a processor to use it across threads, and this may be non-intuitive. Could you take a look at this example https://github.com/tonarino/webrtc-audio-processing/blob/master/src/lib.rs#L324-L382, and let me know how this feels?