Fix receiver SSRC tracking for unsignaled streams

Since https://webrtc-review.googlesource.com/c/src/+/499601,
RTCRtpReceiver.getStats() filters the report by the SSRC that the
receiver tracks on the signaling thread, ssrc_s(). For unsignaled
streams, that SSRC could get out of sync with the worker thread's view:

- Renegotiating without signaled SSRCs reset it to nullopt. If the media
  channel kept the unsignaled stream, no new first packet notification
  followed and the receiver stayed unbound, so getStats() returned no
  inbound-rtp and the receiver's sources stopped updating.
- A first packet notification for a new unsignaled SSRC, e.g. when the
  remote endpoint changed the SSRC, was ignored since the receiver was
  already bound to the previous SSRC.

Track the signaled SSRC and the most recent unsignaled SSRC separately
on the signaling thread, mirroring RtpReceiverBase::ssrc() on the worker
thread. Setting up the receiver only updates the signaled SSRC, and a
first packet for a new unsignaled stream rebinds the first receiver that
doesn't have a signaled SSRC.

Bug: b:575939917
Change-Id: I1dff1ad7ce686322bd0dd60c1fee3557e7a7907e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/510881
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#49023}