Add trunc and interleaved loading in neon and fallback

[LaurenzV]

This adds a couple of more features required for the SIMD version of vello_cpu, in particular:

• Support for the trunc instruction.
• Support for the wrapping_sub instruction.
• Supported for interleaved loading in 128-bit blocks.

[ajakubowicz-canva]

Some initial comments. I am happy with trunc and interleaved loading. However, I think wrapping_sub may be something we don't need to explicitly add. I assume that a followup PR would then need to implement wrapping_* variants of the other math operations.

Maybe it may be useful for @raphlinus to weigh in. Using Highway's design philosophy, they do not separate sub from wrapping_sub. excerpt:

9. Ensuring signed integer overflow has well-defined semantics (wraparound).
   Link

My question is - do we want to provide explicitly different API's for wrapping and non wrapping operations?

Great work!

Edit: I also want to add a caveat that I'm not even close to a reliably source here, hence why I defer to Raph. I won't block review though. I'll try get a chance to review tomorrow.

[LaurenzV]

I'm just not sure that using wrapping_sub in all instances where you have a simple subtraction for fallback might lead to performance issues on some platforms where there isn't an explicit instruction for that. But if highway does it, it's probably fine? After all, the fallback version is usually not expected to be very performant.

Other than that, for me it would be fine to merge the two.

[ajakubowicz-canva]

A quick note that I've reviewed trunc and wrapping_sub and that work LGTM.

I just have interleaved to review but ran out of time. If there's urgency, you could split out those instructions and land incrementally. Otherwise I'll complete review after weekend!

[ajakubowicz-canva]

Sorry for the slow review.

I'm happy with trunc and interleaved but on further thought I don't think we should have sub and wrapping_sub. I think there's a high chance if we add wrapping_sub in this PR, we'll want to remove it in the future (or add more explicit subtraction variants).

[ajakubowicz-canva]

Thank you :D

Great PR!