Code cleanup: remove a duplicate define

Remove multicamera solver option

Reverting the previous commit because Sergey threatened puppies with an axe for every time I add an option.

Add checkbox for multicamera solving

To enable reconstruction using tracks from multiple cameras, the "Multicamera" checkbox in the Solve panel should be checked. This is currently non-functional.

Add simple panel for creating multicamera correspondences

The create correspondence operator is currently non-functional, but it is expected that it will create correspondences between tracks in different movie clips.

Allow empty intrinsics vector for bundle adjustment

If an intrinsics vector is passed to the bundle adjuster with size less than the number of cameras, the vector is padded out to that size with empty intrinsics.

Multicamera-ify bundle adjustment

Bundle adjustment now uses the appropriate camera intrinsics when calculating the reprojection error for each marker. Refinement options are currently only applied to the camera intrinsics for camera 0 (all other camera intrinsics are made constant).

Merging from trunk r60137 into soc-2013-motion_track

Fix crash with fetching all reconstructed views

Scale all camera reconstructions to unity

Multicamera-ify reconstruction initialization

Initialization can now reconstruct from two images regardless of the source camera.

Modify keyframe selection algorithm to be camera-aware

The keyframe selection algorithm can now select keyframes from the camera passed to it as an argument. It's worth looking into multicamera algorithms too.

Improve modal solver image iteration

Instead of iterating over all images and filtering through only those from camera 0, iterate over only camera 0 images. With the current way markers are stored, this is very computationally inefficient, but this should be improved soon.

Use multicamera terminology for initial image selection

To initialise reconstruction, two images need to be selected with high variance. The GRIC and variance algorithm can continue to refer to the images as keyframes, as it is intended to work with images from a single camera, but the libmv API should be more general than that, referring to selected *images*. This is a non-functional change.

Modify modal solver to use only camera 0

Match recent changes to how tracks are stored.

Clearer association between markers and cameras

As the camera identifier associated with a marker is simply bookkeeping for multicamera reconstruction, make it an optional attribute when handling tracks and reconstructed views. This means that the libmv API is still nice for users that don't need to associate images with cameras.

Merging from trunk r60041 into soc-2013-motion_track

Fix: BKE tracking compilation error

Previous commit was incomplete and didn't include blender-side changes to the libmv API.

Modify data structure for storing tracks

The Tracks data structure stores Markers. The current design has it so that a marker's image identifier denotes the frame from the associated camera that the marker belongs to. That is, it treats the image identifier more as a frame identifier. You could have markers in image 0 for camera 0 and image 0 for camera 1 and they wouldn't be considered to be in the same image.

However, this design doesn't make much sense because the reconstruction algorithms don't care about frames or the cameras from which a frame came, only that there is a set of images observing the same scene. A better design is for all frames from all cameras to have unique image identifiers. The camera identifiers can then denote a subset of those images. No image captured by camera 0 will have the same image identifier as images from camera 1. This way, the algorithms can continue to just treat all frames as one big set of images and the camera identifier provides the association of an image to the camera it originated from. This makes it much easier to implement multicamera reconstruction without significant changes to the way libmv behaves.

Update doxygen comments for reconstruction initialization

EuclideanReconstructTwoFrames and ProjectiveReconstructTwoFrames currently assume that the passed markers belong to a single camera. That is, we're not reconstructing frames from different cameras. Ideally, this restriction should be removed.

Code cleanup: Google-style constant names

Google style guide recommends kConstantName for constants.