Propagate the Sframe encryptor to the video RTP send path

Carries the Sframe encryptor created by RtpSenderBase down through the
media channel and call/ layers until it reaches RTPSenderVideo, which
now holds it as a member. Frames are still not encrypted; this CL only
makes the encryptor reachable from the place that will use it.

Flow:
- RtpSenderBase::CreateSframeEncryptorOrError() posts the encryptor to
  the worker thread and hands it to the media channel.
- WebRtcVideoSendChannel::SetSframeEncryptor() stores it in the
  channel's sframe_options_ and pushes the updated options to every
  existing send stream.
- Streams created later pick the encryptor up on their own, because
  AddSendStream copies sframe_options_ into config.rtp.
- RtpVideoSender forwards rtp_config.sframe_options.encryptor into
  RTPSenderVideo::Config, which stores it in sframe_encryptor_.

Details:
- SframeSendOptions gains the `encryptor` handle that was left as a
  TODO when the struct was introduced.
- call/DEPS gets a specific_include_rules entry allowing
  sframe_options.h to include modules/sframe/, which checkdeps
  otherwise rejects for the call/ target.

SetSframeEncryptor no longer takes an ssrc:

- Sframe is Unified Plan only, so a send channel has a single send
  stream and the ssrc carried no routing information - the channel
  never used it to look anything up.
- Storing the encryptor in the channel's sframe_options_ removes that
  ordering dependency entirely: streams that already exist are updated
  through UpdateSframeOptions(), and streams created afterwards read
  the options when they are built. Neither direction needs to know an
  ssrc.

The fail-closed drop in SendEncodedImage() is left unconditional on
purpose. The encryptor is now reachable but unused, so enabling the
`!sframe_encryptor_` half of the check would let plaintext onto the wire
for a stream that negotiated Sframe. The condition stays commented out,
with a TODO, until the following CL adds the encryption itself.

Bug: webrtc:479862368
Change-Id: I6e34c89d086199023dee407edb82641ec95de0f2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/507440
Commit-Queue: Kacper Wasniowski <kwasniow@cisco.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#48801}