Bugfix that fixes the error where the audio processing module is called

using the wrong sample rate for the render signal.

The CL is basically a partial revert of the related changes done on
output_mixer.cc in the CL https://codereview.webrtc.org/1234463003.

The CL also reverts the removal of the input_sample_rate_hz() method
that was removed as part of the CL
https://codereview.webrtc.org/1379123002 (as it was at that point
no longer used).

It should be noted that this CL turns off the effect of the
IntelligibilityEnhancer when the AudioFrame AudioProcessing APIs are
used. While it may be possible to solve that by adding upsampling after
the API call, that  approach was discarded due to that:
-That would add extra processing in the echo path, leading to possible
AEC performance reduction.
-That would add extra complexity for the mobile case.
-That would only patch the intelligibility enhancer operation as the
proper way to do such an operation is within APM.
-The intelligibility enhancer is not active by default anywhere.

BUG=webrtc:5237

Review URL: https://codereview.webrtc.org/1525173002

Cr-Commit-Position: refs/heads/master@{#11045}

webrtc/modules/audio_processing/audio_processing_impl.h

@@ -81,6 +81,7 @@ class AudioProcessingImpl : public AudioProcessing {
   void set_delay_offset_ms(int offset) override;
   int delay_offset_ms() const override;
   void set_stream_key_pressed(bool key_pressed) override;
+  int input_sample_rate_hz() const override;
 
   // Render-side exclusive methods possibly running APM in a
   // multi-threaded manner. Acquire the render lock.