Align MediaDevices access with spec entry-point semantics #43

Summary

There is a spec mismatch in how MediaDevices is accessed in WebRtcNet today.

In the Media Capture spec, app code does not construct MediaDevices. Each Window has an associated MediaDevices object created by the user agent and exposed via Navigator.mediaDevices ([SameObject, SecureContext] readonly). Browser code then calls
avigator.mediaDevices.getUserMedia(...) on that object.

WebRtcNet currently lacks an API-level way to obtain a MediaDevices instance through WebRtcNet.Api, so the example app uses a runtime type-activation workaround (CreateInteropInstance(...)) to construct concrete interop types directly.

Current mismatch and impact

• Spec intent: MediaDevices is a host-provided entry point, not app-constructed.
• Current repo behavior: BasicVideoChat resolves WebRtcInterop.Media.MediaDevices via runtime assembly/type lookup.
• Consequence: client code is coupled to interop implementation details and cannot stay purely on WebRtcNet.Api abstractions.

Why this issue exists

The current workaround in BasicVideoChat is functionally useful but ugly and non-idiomatic relative to the spec model. This issue tracks correcting the API surface so app code can access MediaDevices through a proper public entry point instead of constructing interop types.

Evidence / references

• Spec prose: documents/specs/mediacapture/TR-mediacapture-streams.html (#dom-navigator-mediadevices, around lines 3042-3055)
• Spec WebIDL: documents/specs/mediacapture/mediacapture-idl.webidl (Navigator mediaDevices, MediaDevices interface and getUserMedia)
• Browser usage examples: documents/specs/mediacapture/TR-mediacapture-streams.html (example using
  avigator.mediaDevices.getUserMedia, around lines 4767-4773)
• Current workaround in repo: �xamples/BasicVideoChat/MainWindow.xaml.cs (CreateInteropInstance usage for MediaDevices and RtcPeerConnection)