Add faster probing to GCC startup

[Sean-Der]

To match the behavior of Chromium's implementation as reported by @kcaffrey

I did spend some time digging through the chromium source code, and 
it looks like they are doing a multiplicative increase with an 8%/sec increase
as well, so I think it must converge faster due to the probing it does at the start.

It looked like they might start their estimate at 30Kb/s instead of 10Kb/s, but that 
doesn't make a big difference. Even starting at 30Kb/s, with 1.08 as the multiplicative
 factor, the rate won't reach 1Mb for at least 45sec: 
https://www.wolframalpha.com/input/?i=30000+*+1.08%5Et+%3D+1000000
But chrome reaches it almost instantly, and the only thing I saw in their source that 
could explain that was the probing in the first few seconds. But there is also a lot of 
code in chromium so I haven't read it all yet

[HustCoderHu]

probe_controller.cc
Maybe we need to implement this. It probes bandwidth periodly ( interval time smaller than 1s, may driven by transport_feedback msg, not sure coz i only read the code roughly) in quite short time.

[nils-ohlmeier]

My understanding of how Chrome ramps up the initial bandwidth estimates is that initially uses REMB results and then switches over to GCC once the numbers from GCC have become more reliable.
At least that is the reason we could not just stop offering support for REMB in Firefox after it finally gained support for GCC.