sparse_strips: Introduce Padding type and streamline clip handling

[LaurenzV]

This is part 4 in the prep commit series, based on top of #1746.

The first commit introduces a new PaddingU16 type. On current main, we use kurbo Rect to represent the padding that is derived from a filter. For example, a Rect of (-2, -2, 2, 2,) represents an outward padding of 2 into each direction. This makes somewhat sense, however, we use that same idea to represent a padding using RectU16. I think in the latter case, it doesn't make that much sense anymore. A RectU16 with dimensions (2, 2, 2, 2) represents the same idea as for Rect. But in reality, this is simply a zero-sized rectangle. It doesn't make a lot of sense to use RectU16 to represent the idea of a filter padding. Therefore, this commit adds an explicit padding type so that the semantics are clearer. Methods like intersect and union that exist on RectU16 don't really make much sense if the rectangle represents a padding, like it currently can.

I think using Rect in the first place is also questionable, but at least left/top padding is represented as negative coordinates, so it makes a bit more sense. This change is necessary because the follow-up commit changes how zero-sized rectangles are handled, but for example for offset filters, it would be valid to have a padding in only one direction, while all other sides are 0.

The second commit introduces some changes to how we handle layer clips. To put it briefly, due to the fact that strips always have a fixed height of Tile::HEIGHT and a width with a multiple of Tile::WIDTH, we often need to ensure that bounding boxes are snapped to tile coordinates. Previously, this was done in various places at different times, so very inconsistently. For Vello CPU, we basically only needed this for filter layers, but for Vello Hybrid we will need to make sure that this is also the case for normal layers.

• First, we instead of computing the bbox of clips based on the control points, we simply compute it based on the strips instead. Admittedly, this is probably going to be more expensive for rectangular clips, but on the other hand it's good if we can unify this. But if desired, I can change this back and just snap the control point bbox to tile coordinates again.
• RectU16::INVERTED is now only used as an internal accumulator to represent "no bounding box yet". However, when returning it to the user we always return an empty rectangle instead. This way, we don't have to special case this everywhere.
• The definition of RectU16::intersect is changed such that it cannot produce negative rectangles anymore, also aligning with the kurbo implementation.
• Drawable::bbox must return tile-aligned bounding boxes.
• Some other small fixes, for example to ensure that snap_to_tile_coorindates preserved empty bboxes.

As a consequence, vello_cpu (and in the future vello_hybrid) do not need to do any snapping anymore. All of this is taken care of at the recorder level. There's some more optimizations we should do in the future to prevent zero-sized nodes from being emitted in the first place, but this change by itself is already large enough that I'm going to leave this as a TODO!

I've tested the combination of all 4 PRs against my PDF suite, and didn't see any regressions!

PR train

1. sparse_strips: Move some code from vello_cpu to vello_common #1744 — Move some code from vello_cpu to vello_common
2. sparse_strips: Add more new/refactored code into vello_common #1745 — Add more new/refactored code into vello_common
3. vello_common: Generalize the command recorder abstraction and add more metadata #1746 — Generalize the command recorder abstraction and add more metadata
4. sparse_strips: Introduce Padding type and streamline clip handling #1751 — Introduce Padding and streamline clip handling 👈