Return partial used corners for calibration

[thatcomputerguy0101]

Previously, calibrateCamera would return used corner info for all corners of a board, including those that were not part of the observation. This corrects the problem by changing the input to a list to be able to map the skipped corner info back to the same subset and order that was provided in the parameters. AbstractList can be used on the caller's side to perform on the fly conversion if needed.

[thatcomputerguy0101]

I'm not a big fan of the extra int array for storing ids, but I don't see a better option. AbstractList seems like a better option than iterators for the input data.

[mcm001]

Bigger picture, when we're analyzing data, is it more helpful to return this, or to return every corner (even excluded/ignored/not detected ones)? Does mrcal's other utilities prefer one format over the other? Trying to understand why I might want one or the other

[thatcomputerguy0101]

A lot of PV's analysis handles outlier corners separately from unobserved corners, and once the screen to world coordinate mapping is determined, the ID matters less. In short, OpenCV wants only the observed corners, and MrCal wants padding for all corners. I'm putting together some additional code to verify this flow for the uncertainty PR.

1. ChArUco detection from OpenCV does only observed corners + ids
2. mrcal calibration wants padding (but OpenCV does not)
3. SolvePNP wants no padding
4. Calibration visualization doesn't care about unobserved points.
5. Uncertainty seems to want padding again. I'm not completely sure that it still cares about the order of points here.

[mcm001]

Gotcha. In that case I agree that adding the padding herein mrcal -- the only library who wants it -- makes sense.

Also agree it's worth keeping a distinction between unobserved corners and outlier corners. At some point in the future I'd like to re-run calibration, which would allow a point that was previously an outlier to become an inlier