Using redundant camera libraries

Per the new docs:

Both libraries do camera capture, it's true. The issue is that JavaCV depends on OpenCV for its functionality, and OpenCV doesn't provide camera discovery on all platforms (Windows only). OpenImaj does support camera discovery on all platforms we care about, but it has lots of trouble running successfully on macOS. The latest version of OpenImaj I tested crashed randomly but regularly in normal usage of the camera capture functionality. However the OpenImaj camera discovery feature works just fine, no crashes. Hence we use both. If ever OpenImaj improves its macOS support or if JavaCV supports camera discovery, we could eliminate one or the other.

There are actually a few options/actions we could take on our own without waiting for one or the other of those libraries to update:

1. Work was started in JavaCV to use FFmpeg to do this, but not completed. We could try to complete that work.
2. We could try to rip out just the bits of OpenImaj that does the camera enumeration, and pull those out into some kind of package usable with JavaCV. Probably if we did this we'd drop BridJ (the C++ interop that OpenImaj uses) in favor of JavaCPP (the one JavaCV uses) if at all possible (along with as many other extraneous deps OpenImaj pulls in). The result of this could be a PR for JavaCV, or it could just be a standalone package that we maintain.

Either way, we should be able to also avoid issue #31 entirely witht his work, by using JavaCV only (which doesn't use the VC++ lib) or by updating the VC++ version used if we use the OpenImaj code.

Start with BUILDING.md and the linked JavaCV and OpenIMAJ issue discussions. Compare the proposed options for camera discovery and capture, including their dependency implications. Done means the redundant camera libraries are reduced or eliminated and issue #31 is avoided.