Re: [mediacapture-handle] Expose a MessagePort using Capture Handle (#70)

One lens to look at things through is - if a track is cloned, and the clones are transferred to two different iframes IF_A and IF_B, then:
* Those two iframes should be allowed to communicate to the captured content independently.
* Messages arriving from either should be clearly distinct in the receiver, even if IF_A and IF_B are same-origin.
* Neither IF_A nor IF_B should need to ask the original initiator of the session (who owns the singular CaptureController instance) to do anything more on their behalf.
  * And recall that the capturee could be navigated, which invalidates MessagePorts the original capturer might have produced on behalf of IF_A and IF_B. We don't want IF_A and IF_B to ask the initiator iframe to help each time this happens.
* Anything IF_A sends to the captured content, should not be delivered if the tab was navigated, changed, etc.
* If IF_A tries to send a message to a target that could not possibly receive it, that's an app-bug, and should result in an exception. (Timing issues notwithstanding.)

I believe my proposal addresses all of these, modulo that I need to change:
```webidl
partial interface CaptureController {
  MessagePort getMessagePort();
}
```

To:
```webidl
partial interface MediaStreamTrack {
  MessagePort getMessagePort();
}
```

(Or possibly make CaptureHandle an interface rather than a dictionary, and expose it there.)

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1433386204 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config