feat: add simd support for decode_filter_exp

[CrazyboyQCD]

Added as a reference for other functions, and I personally think slice argument is easier to adapt into simd api than iterator.

CI Changes should be done in another PR.

• Add simd intrinsics
• Multiversioning

[yzsolt]

Hey @CrazyboyQCD, first of all, sorry for taking so long to reply, and of course, big thanks for taking a stab at this!

Overall the changes look good. There are some prerequsites on main though I'd like to have before merging this - things you've already mentioned:

• Iterator vs. slice API: I'd like to explore this topic once all 1.0 changes are ported, and settle on either one, preferably consistent for all meshoptimizer APIs.
• WASM build + CI: planned, and I can take a stab at it soon. I managed to implement WebAssembly SIMD testing on GitHub CI some time ago when adding WASM SIMD support for simdeez.

FYI, originally I was considering simdeez as a possible method of introducing SIMD to meshopt-rs, but I'm not against using intrinsics directly, as you did it.

Let me know if this is important for you, in that case I'll schedule it before the 1.0 porting finishes.

[CrazyboyQCD]

@yzsolt
Thanks for your response.

• Iterator vs. slice API: I'd like to explore this topic once all 1.0 changes are ported, and settle on either one, preferably consistent for all meshoptimizer APIs.

Sure.

• WASM build + CI: planned, and I can take a stab at it soon. I managed to implement WebAssembly SIMD testing on GitHub CI some time ago when adding WASM SIMD support for simdeez.

Great that you have done that before, and I think all the CI changes should be done in another PR, and mine should only focus on implementation.

FYI, originally I was considering simdeez as a possible method of introducing SIMD to meshopt-rs, but I'm not against using intrinsics directly, as you did it.

I was also considering using wide, but I think a similar code structure would be easier to adapt for future changes and also introduces less dependencies.