This reverts commit 8eb37a39e79fe1098d3503dcb8c8c2d196203fed. Chrome now have its own implementation of TaskQueues that is based on Chrome threads.

cl was originally reviewed here:
https://codereview.webrtc.org/2060403002/

- Add task queue to Call with the intent of replacing the use of one of the process threads.

- Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.

- BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.

- VideoEncoderConfig and VideoSendStream::Config support move semantics.

- The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.

TBR=mflodman@webrtc.org
BUG=webrtc:5687

Review-Url: https://codereview.webrtc.org/2250123002
Cr-Commit-Position: refs/heads/master@{#14014}

webrtc/call/call_perf_tests.cc

@@ -672,7 +672,7 @@ TEST_F(CallPerfTest, KeepsHighBitrateWhenReconfiguringSender) {
       encoder_config->streams[0].target_bitrate_bps =
           encoder_config->streams[0].max_bitrate_bps = 2000000;
 
-      encoder_config_ = *encoder_config;
+      encoder_config_ = encoder_config->Copy();
     }
 
     void OnVideoStreamsCreated(
@@ -686,7 +686,7 @@ TEST_F(CallPerfTest, KeepsHighBitrateWhenReconfiguringSender) {
           << "Timed out before receiving an initial high bitrate.";
       encoder_config_.streams[0].width *= 2;
       encoder_config_.streams[0].height *= 2;
-      send_stream_->ReconfigureVideoEncoder(encoder_config_);
+      send_stream_->ReconfigureVideoEncoder(encoder_config_.Copy());
       EXPECT_TRUE(Wait())
           << "Timed out while waiting for a couple of high bitrate estimates "
              "after reconfiguring the send stream.";