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.cc

@@ -501,6 +501,12 @@ void AudioProcessingImpl::SetExtraOptions(const Config& config) {
   }
 }
 
+int AudioProcessingImpl::input_sample_rate_hz() const {
+  // Accessed from outside APM, hence a lock is needed.
+  rtc::CritScope cs(&crit_capture_);
+  return formats_.api_format.input_stream().sample_rate_hz();
+}
+
 int AudioProcessingImpl::proc_sample_rate_hz() const {
   // Used as callback from submodules, hence locking is not allowed.
   return capture_nonlocked_.fwd_proc_format.sample_rate_hz();