setSortBySize seems broken when minArea is used

[ofZach]

Still debugging this but when you do :

finder.setMinArea(10);
finder.setSortBySize(true);
finder.findContours(diff);

and draw just the 1st polyline,it flickers all over -- when you do just

finder.setSortBySize(true);
finder.findContours(diff);

and draw the 1st polyline it's the largest and stable. I'm still debugging it but I wonder if there's some issue around the logic w/ the area calculation -- I notice there are two pathways for the contour code if there is a min/max filter or not....

[ofZach]

I think this is fixed if you change this

if((!needMinFilter || curArea >= imgMinArea) &&
					 (!needMaxFilter || curArea <= imgMaxArea)) {
					allIndices.push_back(i);
                    allHoles.push_back(hole);
                    allAreas.push_back(curArea);
				}

to

			if((!needMinFilter || curArea >= imgMinArea) &&
					 (!needMaxFilter || curArea <= imgMaxArea)) {
					allIndices.push_back(i);
                    
				}
                allHoles.push_back(hole);
                allAreas.push_back(curArea);

this fixed something wrong about the sort logic since we are storing a "thinned" down area vector but our indices relate to allContours -- so i think there's some mis-match.... this fix stores all area and holes which I think makes sense given how indices is working.

worth another pair of eyes....

[kylemcdonald]

I'm going to leave this up unless someone can test this more rigorously, especially checking how this relates to #202 . I think a lot of ofxCv is good, but some of this logic inside ContourFinder and Tracker I don't trust completely. Both are well intentioned but poorly implemented in a way that has lead to some hard-to-debug edge cases.