simd: Generic-T Simd<T,W> abstraction

[swahtz]

Summary

This PR adds openvdb/simd/Simd.h — a zero-dependency SIMD wrapper that lets code be written once as templates on a value type T and compiled for both scalar (T=float/double) and W-wide SIMD (T=Simd<float,W>) paths without #ifdef or duplicated logic. Two backends are selected automatically at compile time:

• Backend A (OPENVDB_USE_STD_SIMD): wraps std::experimental::simd (C++ Parallelism TS v2), emitting native vector instructions directly without relying on the auto-vectorizer.
• Backend B (default, C++17): wraps std::array<T,W> with fixed-count element-wise loops, which auto-vectorizers produce equivalent SIMD code from.

Migration to std::simd (C++26) will be a one-line change in the backend detection guard; all call sites remain unchanged.

Proposed Benefits

• Dependency Management: Introduce VCL, SIMD wrappers, and Vectorized RasterizeSDF(Spheres) #2190 introduces a new dependency on the VCL library. We have an alternative approach that replicates the API/semantics of std::simd<type, width> (either by a thin C++17-compatible emulation layer, or as a wrapper for the STL-proposed types) that introduces no new dependencies and is supported via <experimental/simd>.
• Hardware Portability: The VCL approach is strictly limited to x86 and does not support other ISAs. ARM support is increasingly critical for platforms such as Apple Silicon and NVIDIA's Grace CPU. Our alternative approach natively supports both architectures as well as SIMD on other ISAs (e.g. RISC-V, POWER, Qualcomm's Hexagon) via the compilers' auto-vectorizer.
• Performance Parity: While VCL guarantees SIMD code generation, our preliminary tests show that our method generates almost identical SIMD instructions with -O2 or higher on both GCC and Clang. In practice, there does not appear to be a significant performance benefit compared to using VCL.
• Single-Source Portability: VCL potentially requires 2 separate implementations of kernels, one for scalar CPU (or CUDA), and one for SIMD CPU (using simd::op() methods), whereas our approach is truly single-source. You write the code once, and it works seamlessly across CPU scalar, GPU/CUDA, and SIMD environments.
• Architectural Flexibility: The VCL approach hardwires the width of data-level parallelism to the current architecture (e.g., 8 floats on AVX2, 16 on AVX-512). Our approach—aligning with what std::simd has converged on—makes the data width a programmatic decision rather than an architectural one. This offers significant advantages for handling padding and memory alignment.
• Sustainability/Maintenance: The VCL library ultimately depends on intrinsics to emit assembly-level code. This requires maintenance of the operator set, even within the x86 architecture. Any new operator that is introduced in a newer generation of x86 will default to a Tuple<type,width> scalar implementation, until a maintainer introduces the respective intrinsics in our VCL clone. Our alternative has the potential to use the autovectorization capability of compilers to target newer architectures as they emerge.