Check for NV_DX_interop extension available and fallback mode

[marcotod1410]

At this current time, this control only works if the NV_DX_interop is supported. If the extension is not supported, an AccessViolationException is thrown. This happened to me on a virtual machine where 3D acceleration was enabled via a virtual Mesa graphics card.

I've got the following questions:

• Should we check for the NV_DX_interop extension support before creating the DXGLContext? If so, should we expose a dependency property and/or an event when the initialization fails? Doing so, the control could notify the user about the issue, so that the error can be handled correctly by the application.
• If the extension is not supported, should the library provide a fallback mode for rendering? I was thinking also about the rendering mode used before the NV_DX_interop way was introduced (rendering to an hidden window, then copying the buffer to a WriteableBitmap).

[NogginBops]

I think we should fall back (or at least have the option to fall back) to a version that does that CPU roundtrip if interop is not supported.
And making sure the user can query if they got a fast backend or a slow one.