Fix: Fix Multi-Video Stream Playback and Internal Frame Stealing

[sqrrrl]

This PR addresses a bug where only one video stream would play at a time, even when multiple streams were requested. The fix involves resolving a "frame stealing" issue in the internal library and implementing
automatic layout repetition to simplify client-side configuration.

Changes

Internal Library Logic

• Resolved "Frame Stealing": Removed the use of MediaStreamTrackProcessor in InternalMeetStreamTrackImpl. The previous implementation was consuming and closing frames to detect SSRCs, which prevented those frames
  from reaching the DOM
• Non-Intrusive SSRC Polling: Replaced the processor with a non-intrusive polling mechanism that uses RTCRtpReceiver.getSynchronizationSources() and getContributingSources(). This allows the library to identify and
  assign tracks to media entries without interrupting the media flow.
• Automatic Layout Repetition: Updated MeetMediaApiClientImpl.applyLayout to automatically repeat the last provided MediaLayoutRequest if the number of requests is fewer than the numberOfVideoStreams configured at
  session start. This maintains backward compatibility with simpler client implementations while ensuring all requested streams are active.
• Assignment Optimization: Refined VideoAssignmentChannelHandler and MediaEntriesChannelHandler to only trigger the assignment search for tracks that do not already have an associated media entry, reducing redundant
  processing.

Sample Application

• Stability: Added explicit .play() calls to media elements upon assignment to ensure reliable playback across different browser autoplay policies.

Verification Results

• Build: Successfully verified with npx webpack in the samples directory.
• Functionality: Verified that multiple video streams now play simultaneously even when only a single media layout is explicitly provided by the client.