Motion tracking: automatic keyframe selection

This commit contains implementation of automatic keyframe selection algorithm
based on Pollefeys's criteria (F-GRIC is smaller than H-GRIC and correspondence
ratio is more then 90%). It is implemented as a part of simple pipeline and
returns vector of keyframe images for a given Tracks structure.

For simple pipeline reconstruction two best keyframes are selecting from list
of all possible keyframes. Criteria for this selection is reprojection error
of solution from two candidate keyfames.

In Blender side added an option in Solve panel to enable Keyframe Selection.
If this option enabled, libmv will detect two best keyframes and use them for
solution. This keyframes will be set back to the interface when solution is
done.
Camera tracking: fix for incorrect two ketframe selection criteria

Reprojection error of a solution should be calculated for tracks in
image space, not in normalized space.
Merging r52852 through r52894 from trunk into soc-2011-tomato
Camera tracking: fixed for automatic keyframe selection

Previously GRIC wasn't working because of typo in getting vector
dimension which are vector-columns, not vector rows.

This implied some additional changes to make selector working nicer:

- lambda coefficients in GRIC were changed form natural to base-10,
  otherwise sums of rho functions are much smaller than constant
  part of GRIC.
  This also seems to correlate with papers where log() usually means
  base-10 logarithm.

- Limited correspondence ratio from top, which will give better
  results because it usually means longer base line.

- Made logging more useful.
Merging r52895 through r53202 from trunk into soc-2011-tomato
Merging r53203 through r53211 from trunk into soc-2011-tomato
Tomato: added missing files to template generator
Tomato: syncronize with changes in libmv branch with assorted fixes

- Biggest error was in cost functors used for F and H refirement,
  they were just wrong.

- Use natural logarithms, since it's actually makes sense from
  math papers point of view and error is somewhere else.

- Disabled rho for GRIC, for now use non-clamped error for tests.

- Made SymmetricEpipolarDistance returning non-squared distance
  Keyframe selection is currently the only used of this function
  and it seems using non-squared distance makes much more sense.

  Also would think to append suffix "Squared" to functions which
  returns squared distances.

- Removed templated version of SymmetricEpipolarDistance, since
  it's not needed actually.

- Changed main keyframe selection cycle, so in cases there're no
  more next keyframes for current keyframe could be found in the
  image sequence, current keyframe would be moved forward and
  search continues.

  This helps in cases when there's poor motion in the beginning
  of the sequence, then markers becomes occluded. There could be
  good keyframes in the middle of the shot still.

- Moved correspondences constraint to the top, so no H/F estimation
  happens if there's bad correspondence. Makes algorithm go a bit
  faster.

Selection still behaves very much fuzzy and still working on this.
Merging r53212 through r53624 from trunk into soc-2011-tomato
Merging r53625 through r53627 from trunk into soc-2011-tomato
Fixed for keyframe selection

- Calculate residuals for GRIC in pixel space rather than
  in normalized space.

  This seems to be how it's intended to be used.

  Algebraic H and F will still use normalized coordinates which
  are more stable, after this matrices are converted to pixel
  space and Ceres refinement happens in pixel space.

- Standard deviation calculation was wrong in GRIC. It shouldn't
  be deviation of residuals, but as per Torr it should be deviation
  of measurement error, which is constant (in our case 0.1)

  Not sure if using squared cost function is correct for GRIC,
  but cost function is indeed squared and in most papers cost
  function is used for GRIC. After some further tests we could
  switch GRIC residuals to non-squared distance.

- Bring back rho part of GRIC, in unit tests it doesn't make
  sense whether it's enabled or not, lets see how it'll behave
  in real-life footage.

- Reduce minimal correspondence to match real-world manually
  tracked footage

- Returned back squares to SymmetricEpipolarDistance and
  SymmetricGeometricDistance -- this is actually a cost
  functions, not distances and they shall be squared.
Merging r53628 through r54569 from trunk into soc-2011-tomato
Motion tracking dopesheet

Highlight background depending on number of tracks existing on frame.

This is not so much mathematically accurate displaying where things
shall be improved, but it's nice feedback about which frames better
be reviewed.

Bad frames are tracks < 8, highlighted with red.
OK-ish frame  are 8 <= tracks < 16, highlighted with yellow.

Could be some artifacts with color region start/end, this is a bit
unclear what exactly expected to be highlighted -- frames are
displayed as dots, but in fact they're quite noticeable segments.
Merging r54570 through r54750 from trunk into soc-2011-tomato
Merging r54751 through r54845 from trunk into soc-2011-tomato
Merging r54846 through r54847 from trunk into soc-2011-tomato
Oh bummer, it's too early for this patch to be in!
Merging r54848 through r55059 from trunk into soc-2011-tomato
Merging r55060 through r55079 from trunk into soc-2011-tomato
Merging r55080 through r55271 from trunk into soc-2011-tomato