Switch masonry_testing to using vello_cpu and tweak screenshot defaults

[PoignardAzur]

This PR changes the way masonry_testing relates to imaging. Previously, masonry_testing imported masonry_imaging and could swap in any number of backends. This was not desirable for several reasons:

• Backends have small differences in how they render some scenes. These differences are invisible to the naked eye but strong enough to fail screenshot tests even with a high per-pixel tolerance. There is no way to check Masonry's screenshot test suite with both vello_cpu and vello classic, we need to pick one and stick to it.
• Because of the overhead (on some platforms) of setting up a GPU context once per test, masonry_testing really wants a software renderer backend. Given a choice between vello_cpu and vello_hybrid, we will never choose vello_hybrid.
• The backend-dispatching abstraction is rather messy, whereas using vello_cpu only is very simple. The entire test renderer is 40 lines long.

See #masonry > Switching masonry_testing to vello_cpu for some discussion and perf numbers.

Running cargo test -p masonry --lib goes from 35.8s to 2.0s when all tests pass

Because this PR inevitably needs to regenerate all screenshots, it also does two minor changes to defaults which also affect screenshots:

• Make the padding color the same as the background color. This is because we want widget with padding to give the impression they're "floating" in a larger widget.
• Remove all the overridden properties in test_property_set(), making it the same as default_property_set() until we change stuff again.
  • This required tweaking two unit tests that relied on Label having padding.

I've manually checked that, before applying these two changes, the only changes to screenshots for switching renderers were minor one-pixel differences or slight changes in gradient values.

Other changes:

• Remove some code from masonry_imaging that was used in masonry_testing only.
• Remove dependency on futures-intrusive.

[PoignardAzur]

(Speaking of tolerance, I should probably try lowering the tolerance value of the screenshot tests, since AFAIK they're supposed to be deterministic now.)

[xStrom]

I think that doing most Masonry tests with one rendering backend makes sense. The goal after all is to test Masonry, not whether the rendering backends all produce the same results. Those tests should live elsewhere, possibly in imaging.

That said, some sort of basic sanity check of other renderers working at all should probably exist, but that can be in masonry.

The speed and hardware/environment compatibility benefits of using Vello CPU are very strong. Indeed, I can't wait for us to provide Vello CPU as a serious choice also for Masonry proper. Because those benefits also exist in certain real app scenarios.

Overall, I think we can move forward with this. If we at some future point want to re-introduce more imaging backend support for masonry_testing, that won't be too much work either it seems.

[xStrom]

This is a great example of vello#1499, a Vello Classic bug not existing in Vello CPU.

[xStrom]

Looks like Vello CPU floors instead of rounds, at least from the middle. Interesting impact on stuff like progress bars.