Refactor RtpSender and SSRCDatabase.

* SSRCDatabase doesn't need to be a global instance, so I've changed it to be a "regular" class (i.e. construct via ctor, not maybe via GetSSRCDatabase( + release via ReturnSSRCDatabase())).  If we ever have parallel tests running in the same process, they won't have the problem of using the same ssrc database.

* Made RtpSender a more const.  Also added some todos for myself and holmer to look into clarifying the threading model.

* Switched from CriticalSectionWrapper to rtc::CriticalSection

* Changed the random seeding to use TickTime::Now().Ticks() since TimeInMicroseconds() could return 0 when the process was starting.  This is what TimeInMicroseconds() does anyway but now we don't need to access a global clock object.

BUG=webrtc:3062

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

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

webrtc/base/random.h

@@ -21,6 +21,17 @@ namespace webrtc {
 
 class Random {
  public:
+  // TODO(tommi): Change this so that the seed can be initialized internally,
+  // e.g. by offering two ways of constructing or offer a static method that
+  // returns a seed that's suitable for initialization.
+  // The problem now is that callers are calling clock_->TimeInMicroseconds()
+  // which calls TickTime::Now().Ticks(), which can return a very low value on
+  // Mac and can result in a seed of 0 after conversion to microseconds.
+  // Besides the quality of the random seed being poor, this also requires
+  // the client to take on extra dependencies to generate a seed.
+  // If we go for a static seed generator in Random, we can use something from
+  // webrtc/base and make sure that it works the same way across platforms.
+  // See also discussion here: https://codereview.webrtc.org/1623543002/
   explicit Random(uint64_t seed);
 
   // Return pseudo-random integer of the specified type.