Feature/t value comparison

[adamwulf]

Fixes a number of issues found when debugging the union test cases. One helpful thing is the new ability to calculate the 'effective t-value distance' between two points. Added quite a few test cases in MMClippingBezierGeometryTest to both verify and describe how it works.

- (void)testTValueIgnoreLineSegment2
{
    UIBezierPath *path = [UIBezierPath bezierPath];
    [path moveToPoint:CGPointMake(0, 0)]; // 0: ignore this element
    [path addLineToPoint:CGPointMake(0, 100)]; // 1: [0, 100]
    [path addLineToPoint:CGPointMake(0, 200)]; // 2: [100, 200]
    [path addLineToPoint:CGPointMake(0, 300)]; // 3: [200, 300]
    [path addLineToPoint:CGPointMake(0, 300)]; // 4: ignore this element
    [path addLineToPoint:CGPointMake(0, 300)]; // 5: ignore this element
    [path addLineToPoint:CGPointMake(0, 300)]; // 6: ignore this element
    [path addLineToPoint:CGPointMake(0, 300)]; // 7: ignore this element
    [path addLineToPoint:CGPointMake(0, 400)]; // 8: [300, 400]
    [path addLineToPoint:CGPointMake(0, 0)]; // 9: [400, 0]
    [path closePath];

    CGFloat dist = [path effectiveTDistanceFromElement:4 andTValue:0.005 toElement:6 andTValue:0.995];
    XCTAssertEqualWithAccuracy(dist, 0.0, 0.000001);

    dist = [path effectiveTDistanceFromElement:3 andTValue:0.5 toElement:6 andTValue:0.95];
    XCTAssertEqualWithAccuracy(dist, 0.5, 0.000001);
}

in the above, those additional lines to (0, 300) don't actually move the path at all. so if we calculate an intersection at the end of element 3 and start of element 6, the path hasn't moved at all between those, so we should consider them equal intersections.

this helps reduce duplicate intersections that are otherwise found when we're calculating element by element.

[julsh]

Nice improvement! Looks like there's a conflict with the base branch but I'd be 👍 on merging this!