vello_hybrid: A complete rewrite of the core logic (#1759)

Also, I know the number of added/removed lines looks scary, but a
significant part of this is just tests and also shuffling existing code
around. 🙂 But obviously it's still a big PR! Initially, the plan was to
try to split it up, but after discussing with Alex we've come to the
conclusion that it makes more sense to deliver it as a whole "package".

# Summary
This PR implements a major rewrite of Vello Hybrid. The WebGL and WGPU
backends as well as some core aspects of old Vello Hybrid (like how
paints and filter are encoded remain mostly the same), but the core
algorithm for interpreting and scheduling scene commands has been
completely reworked. More information on what motivates this change can
be found in an adjacent [Zulip
thread](https://xi.zulipchat.com/#narrow/channel/197075-vello/topic/Removing.20coarse-rasterization.20based.20clipping/with/590142140)
as well as in some render office hours transcripts, but to summarize it
very briefly:

Vello Hybrid is currently based on a so-called “coarse rasterization”
approach, where render work is split up into wide tiles that can be
rendered independently. One of the core motivations for doing so was to
enable doing blending with bounded memory. However, as Vello Hybrid
evolved, it turned out that the approach is not great, for two reasons.
First, the CPU overhead for doing coarse rasterization is so big that it
basically diminishes any of the performance characteristics we would
expect from a GPU-based renderer. Secondly, coarse rasterization is
fundamentally incompatible with filters, where the whole layer needs to
be rendered on its own first. This goes against the core idea of corse
rasterization, where the viewport is split up and it is assumed that
each wide tile can be rendered independently.

Because of the above,
1. Vello Hybrid now basically has two separate paths, the old
coarse-rasterization based path and a new “fast strips path”, which
attempts to regain the performance benefits for simple scenes without
layers.
2. In order to support filters, we had to resort to _a lot_ of hacks to
make them work with coarse rasterization, especially to support them in
combination with layer clipping. The code is incredibly complex and hard
to reason about, making it hard to maintain it. There are also a few
open issues with bugs. In addition, the current approach also makes it
impossible to support filter layers that extend over the root viewport;
currently, any filter effect that isn't in the main viewport area is cut
off.

Vello CPU was also plagued by similar problems, which we’ve fixed by
rewriting it to use a simpler coarse rasterization approach (see #1701),
in my opinion with great success!

This PR does the same, but for Vello Hybrid. Unlike Vello CPU, which
does still need some form of coarse rasterization to work efficiently,
for Vello Hybrid we do not need this at all. Therefore, it's completely
removed. Instead, we just submit the "soup of strips" directly to the
GPU and let it take care of the rest. From my testing, not only does it
solve our existing problems, but it also greatly improves performance of
layers, especially on low-tier devices, and makes the overall
architecture of Vello Hybrid more consistent, better tested, much easier
to reason about and more memory-efficient for scenes with many filters.

# Showcases
I will try to add some showcases tomorrow.

# Changes

I will not dive into the real "meat" of this PR too much here, because
I've already extensively documented how it works in the code. But I will
still give a list of the overall changes, also give a suggested order
for reviewing this PR.

## vello_common

Thanks to the preparatory PRs that have already been merged, the only
changes are updating some references to files in comments.

## vello_sparse_shaders

I've renamed the shader files to make their naming a bit more
consistent. The blending logic has been extracted into a separate shader
since it's a completely independent stage now. I've also added a new
`copy` shader and repurposed the existing `clear_slots` shader. Other
than that, I also did some renaming of variables in the existing shaders
to make them consistent. Apart from that, everythin should be the same.

## vello_sparse_tests

With this PR, we can finally get rid of the scene constraints, as we can
completely transparently handle scenes where the root is a blend target,
all while still retaining the best speed benefits for both cases! Apart
from that, I've also added a bunch of new test cases to get more
coverage for the new code.

## vello_hybrid
Staring with the easier part, I've deleted the old `schedule` module,
since it's replaced with a new algorithm. The fast rect path has been
extracted into a new `rect` module and paint-handling into `paint`.

The new modules `blend` and `copy` are for GPU-side preparation of those
stages. I've also made changes to `filter`, but the core idea of how
filters are handled is the same, except that it's completely integrated
into the new layer-scheduling mechanism. As a consequence, we do not
pollute the image atlas for filters anymore! `scene` has been rewritten
to use the new recording mechanism, and the new `target` module
provides. In `util`, I've added a new abstraction to allow viewing
non-contiguous ranges of slices in a buffer as a single contiguous ones.

Above are the easy changes, but from then on things get more tricky, and
I'm unsure what the best way to review them is. 😄 I would probably start
by reading the doc comments of all modules in `schedule` to get the
basic idea behind the new scheduling algorithm. Then, it probably makes
sense to go bottom-up, by reviewing independent modules like `draw`
(which should be familiar to already-existing code), `target`, followed
by `allocate`, `execute` and `cursor`. Those basically form the building
blocks of the new scheduling algorithm and can kind of be understood
independently. After that, I'd recommend reading through `round`, which
forms our representation of an independent set of render passes executed
as a unit. And finally, the biggest part is in `schedule/mod.rs`, which
ties all of the other elements together to implement what we need.

# Follow-ups

- With this PR merged, coarse rasterization in `vello_common` is
essentially dead code. However, I will wait until this PR is merged
before actually deleting the module, as there are some other places that
still use `WideTile::WIDTH`, and I don’t want to make the diff larger
than it already is!

This PR was done with assistance of GPT 5.6 Sol, but it goes without
saying that I’ve heavily guided and thoroughly reviewed this
implementation, to make sure it’s robust and lives up to our standards.
It’s possible that a comment might have gotten lost here and there as
part of moving code around, but I tried my best to find and fix those
before opening this PR. I’ve also gone through a lot of iterations to
arrive at this point, so it’s possible there is some accidental or
unnecessary complexity somewhere that I missed.