Avoid acquiring VCM::_receiveCritSect during decode callback.

When VideoDecoder::Decode, Reset, or Release is called,
VideoCodingModuleImpl::_receiveCritSect may have been
acquired. Decode callback needs to acquire the same lock
in ViEChannel::FrameToRender. It is not a problem for
SW decode because decode callback is run on the same
WebRTC decoding thread and the lock is re-entrant. But
for HW decode, decode callback is run on a thread different
from WebRTC decoding thread. Decode callback gets the locks
in the opposite order. Deadlock can happen.

BUG=http://crbug.com/170345
TEST=Try apprtc.appspot.com/?debug=loopback on ARM Chromebook Daisy.
     Run libjingle_peerconnection_unittest.

R=stefan@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/1997005

git-svn-id: http://webrtc.googlecode.com/svn/trunk@4523 4adac7df-926f-26a2-2b94-8c16560cd09d

webrtc/modules/video_coding/main/interface/video_coding_defines.h

@@ -98,6 +98,8 @@ class VCMReceiveCallback {
       const uint64_t pictureId) {
     return -1;
   }
+  // Called when the current receive codec changes.
+  virtual void IncomingCodecChanged(const VideoCodec& codec) {}
 
  protected:
   virtual ~VCMReceiveCallback() {