Migrate Skia to m143 and SkPathBuilder

[anthrotype]

This PR updates skia-pathops to use Skia m143 (chrome/m143) and migrates from mutable SkPath to immutable SkPath with SkPathBuilder for path construction.

Skia is removing mutability from SkPath (tracked in issue 40040287) to make it immutable and thread-safe. The deprecated mutable path methods (moveTo, lineTo, etc.) are now hidden behind SK_HIDE_PATH_EDIT_METHODS and will be removed in a future Skia release.

The core changes by @bungeman in 386fea4 update the Cython bindings to use the new skia API. The rest is me updating the skia-builder to m143 and ensuring the existing skia-pathops Python API remains unchanged.

There are still three test failures seemingly due to Skia m143 behavioral changes which I still need to investigate.

[anthrotype]

Regarding the 3 remaining test failures, I can confirm they are the result of intentional behavior changes in latest Skia (I don't exactly know from which version on, but it's evident in m143).

1. OpBuilderTest::test_resolve: the test contains a pathological input (a path with an extreme spike at hundreds of millions of units), the new skia simplifies away this degenerate artifact, so I think we should just update the test.

2. PathTest::test_allow_open_contour: this used to confirm that two consecutive moveTo() calls produced two single-point contours. In Skia m143 the builder now overwrites any preceding standalone kMove (SkPathBuilder::moveTo replaces the last point instead of appending), so by the time the second moveTo runs the first move point is already gone. See https://skia-review.googlesource.com/c/skia/+/1033357

3. test_reverse_path[operations11-expected11]: this failure is somehow related to the previous one, but distinct; the test feeds a path with only a single moveTo through Path.reverse() and expects that it survives the reversal unchanged. Even if SkPathBuilder keeps the verb (when not overwritten by another consecutive moveTo, as per above), the new SkPathIter explicitly trims any trailing kMove verbs at the end of a path (see include/core/SkPathIter.h), so when we iterate over the contours we see nothing and the reversed path is empty. See https://skia-review.googlesource.com/c/skia/+/1041696

So basically we can no longer store and get back contours that consists of nothing but a single moveTo(x, y) as they won't survive once they touch SkPathBuilder or SkPathIter.

It's true that single-point contours can be found sometimes in font land e.g. used as points to anchor components or marks (font source formats nowadays store things like that as distinct "anchors" rather than as part of the contour outlines).

But even when we were using the old skia m113 with mutable SkPath, as soon as we passed those single-point paths through PathOps (Path.simplify, Path.op, OpBuilder, etc.) they were already doomed because a lone moveTo never emits an edge so the result path would come back without it. The only reason those two tests ever saw them was they hadn’t been fed into PathOps yet; they were really validating storage details that the latest Skia no longer preserves.
And people call into skia-pathops specifically to run the boolean ops, not merely to round-trip glyph anchors. Therefore I'm going to adjust the expectations to match m143 and document the behavioral change: single-point open contours are now dropped during path construction/iteration, and any PathOps call will discard them too.

[bungeman]

The SkArcSize not being SkPathBuilder::ArcSize makes me a little uneasy, but it's fine. LGTM (though I don't see any buttons to push as I don't think I have any real permissions here).

[anthrotype]

Yeah, that was to mirror what we do with other similarly nested enums. I think as a follow up we could expose the new SkPathBuilder API to the Python level (a PathBuilder companion to Path) to mimic more closely the actual Skia interface, then I can have the ArcSize enum nested in there among other things. But not hugely urgent in my opinion.