Fix unsynchronized access to mid_to_transport_ in JsepTransportController

* Added several thread checks to JTC to help with programmer errors.
* Avoid a few Invokes() to the network thread here and there such
  as for fetching sctp transport name for getStats(). The transport
  name is now cached when it changes on the network thread.
* JsepTransportController instances now get deleted on the network
  thread rather than on the signaling thread + issuing an Invoke()
  in the dtor.
* Moved some thread hops from JTC over to PC which is where the problem
  exists and also (imho) makes it easier to see where hops happen in
  the PC code.
* The sctp transport is now started asynchronously when we push down the
  media description.
* PeerConnection proxy calls GetSctpTransport directly on the network
  thread instead of to the signaling thread + blocking on the network
  thread.
* The above changes simplified things for webrtc::SctpTransport which
  allowed for removing locking from that class and delete some code.

Bug: webrtc:9987, webrtc:12445
Change-Id: Ic89a9426e314e1b93c81751d4f732f05fa448fbc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205620
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33191}

pc/jsep_transport_controller_unittest.cc

@@ -904,6 +904,9 @@ TEST_F(JsepTransportControllerTest, IceSignalingOccursOnSignalingThread) {
   EXPECT_EQ(2, candidates_signal_count_);
 
   EXPECT_TRUE(!signaled_on_non_signaling_thread_);
+
+  network_thread_->Invoke<void>(RTC_FROM_HERE,
+                                [&] { transport_controller_.reset(); });
 }
 
 // Test that if the TransportController was created with the