Save old TCC feedback timestamps, in case of packet reordering.

[JonathanLennox]

Based on libwebrtc's equivalent code (as used in Chrome) -- see https://webrtc.googlesource.com/src/+/refs/heads/master/modules/remote_bitrate_estimator/remote_estimator_proxy.cc .

[bbaldino]

lgtm

[bgrozev]

This is a bit concerning because:

1. The map will usually contain ~500ms worth of packets (~150-200 packets).
2. removeIf is linear
3. removeIf will execute once per sent TCC feedback

Are any of my premises wrong?

[JonathanLennox]

I don't think they are. I'll try profiling it and see what I find.

Chrome does the same thing (it uses an explicit for loop with an iterator rather than a lambda but the semantic is the same) but of course it's only sending one source, so presumably less media, and also the computational cost compared to a browser is relatively much less than an SFU.

In theory if we used an explicit loop we could terminate the search by entry.key, but I'm pretty sure that in the normal cases this wouldn't be much of a win since tccSeqNum will be greater than any previous key anyway.

[JonathanLennox]

Here's the performance of TccGeneratorNode.observe() before and after my patch:

So it is a noticable relative increase, but not that large an absolute increase as a percentage of the total bridge time.

[JonathanLennox]

Since most of this PR ended up in #222, I've rebased this one to have just the remaining part.