Previously, we had a single usb context for everyone.
This was causing the usb context thread handler to be overloaded
and signficantly reduced performance (and possibly caused frame
corruption?).

As of this commit, CPU consumption for uvc devices is greatly reduced
(although still not on pair with devices using direct show!).

Tested on Windows 8.1 and Windows 10.

One issue was observed during tests with this new context setup.
Sometimes when reinitializing (e.g., changing the framerate or resolution),
the uvc stream will be initialized without errors, but we only receive a
single (sometimes corrupted) frame back; afterwards, no new frames are
received.
Reopening the camera seems to solve the issue, so this is low priority
atm.

When using 640x480 @ 120 FPS and the processing can't keep up with
the frame rate, some glitches start showing in the images; these commit
adds some additional options that were used during test and might be
useful in the future.

I'm not entirely sure where these glitches come from, but it seems they originate
within libuvc.
After tracing it back to this point, increasing
LIBUVC_NUM_TRANSFER_BUFS  seems to get rid of the bug.
However, setting it too high impedes opening all three pupil cameras.

Temporary solution is to make sure processing can keep up with the
framerate (e.g., by downsizing the processing input in EyeRecToo).

When experimenting with multiple cameras on separate threads sometimes
uvc_open would return UVC_ERROR_NOT_FOUND.