Future camera API work...

[icculus]

All of this is not for 3.2.0 (unless we want it to be), but I wanted to make sure this isn't lost now that we've merged the camera stuff.

• WinRT has a separate camera API from win32. It's not clear to me if Media Foundation is not available to WinRT at all, so it needs it's own implementation, or if our existing win32 code can work there, and the WinRT-specific API is just to give it a C++ wrapper. Someone should try the existing win32 code, if nothing else.
• Haiku has a webcam API, but it wasn't clear what their driver support, etc, looks like at the moment. There's at least one app that uses the API (named CodyCam), which I believe is open source. I haven't looked further, and don't intend to right now.
• Our Media Foundation (win32) code doesn't support hotplug. It either needs RegisterDeviceNotification, which needs a HWND to receive events. That might be a pain, but it works back to WinXP. CM_Register_Notification uses callbacks instead of a HWND, but is Win8+ only and might be a different pain in the butt.
• CoreMedia (macOS/iOS) doesn't have hotplug either; there are two ways to do it, depending on what version of macOS you're on, but it's (probably?) not hard to implement both.
• Platforms that provide their own device thread will not work with the Zombie fallback implementations unless they continue to call the device thread's Iterate function at a regular frequency, but most probably fail to do so once the device is lost. Could be interesting to try spinning a thread at that point to take over. Doing nothing in this case just means SDL_AcquireCameraFrame() just returns NULL immediately instead of providing blank frames for lost hardware.
• Several backends are forced to allocate and copy frame pixels because SDL_Surface doesn't support planar surfaces that aren't tightly packed into a single pixels field atm. This would need an API change to SDL_Surface that we would take advantage of internally, but the camera API itself would not change.
• There was a request for hardware access to camera frames (ideally so you can move images directly from the camera to some place GPU-accessible without copying data around. I'd be nervous about complicating the existing API and code to support this, but if we can do it with a minimum of drama, let's do it.

[icculus]

Platforms that provide their own device thread will not work with the Zombie fallback implementations unless they continue to call the device thread's Iterate function at a regular frequency, but most probably fail to do so once the device is lost. Could be interesting to try spinning a thread at that point to take over. Doing nothing in this case just means SDL_AcquireCameraFrame() just returns NULL immediately instead of providing blank frames for lost hardware.

Halfway through typing this, I realized the zombie thing is silly and we should just provide the blank frames right in SDL_AcquireCameraFrame() and not worry about threads for failed/disconnected cameras.

[icculus]

Windows hotplug has a separate issue tracking it, that we should try to get into 3.2.0 if possible: #9455