Associate audio streams with their source/destination RenderView.

Associate audio streams with their source/destination RenderView.

This is a first step towards implementing three major Chromium features, all of which need to associate audio outputs with their source tabs.  See BUGs referenced by this change for more details.

Previous attempt/approach: https://codereview.chromium.org/11166002/

Specifics:

1. Added two new IPC messages: AudioHostMsg_AssociateStreamWithProducer and AudioInputHostMsg_AssociateStreamWithConsumer.
2. Added "associate to render_view_id" IPC calls: PepperPlatformAudioInputImpl, PepperPlatformAudioOutputImpl, RenderAudioSourceProvider, RendererWebAudioDeviceImpl, WebRtcAudioRenderer.
3. AudioOutputDevice instances re-use the same stream IDs.
4. Removed AudioDeviceFactory and replaced test-injection scheme in AudioRendererMixerManager.

Not in scope:

1. Associating RenderViews with audio input to WebRTC.
2. Associating RenderViews with streams produced by the AudioRendererMixer.
3. Speech Input (implementation is in the browser process, not the render process).

Testing method: Confirm correct render_view_id shows up in debug logging when engaging the various audio code paths.  Some of the many test sites used:

1. PPAPI (in and out): http://www.midomi.com/index.php?action=main.mic_check
2. WebMediaPlayer (e.g., <audio> and <video>): http://html5video.org/
3. WebAudio API: http://chromium.googlecode.com/svn/trunk/samples/audio/convolution-effects.html
4. WebRTC (output only): http://apprtc.appspot.com/

BUG=3541,64215,153392
TEST=Enabled debug logging via --vmodule=audio_renderer_host=1,audio_input_renderer_host=1 and then engaged the various Chrome audio code paths to confirm correct render_view_id shows up in browser process.

Review URL: https://chromiumcodereview.appspot.com/11359196

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@170919 0039d316-1c4b-4281-b951-d872f2087c98