Add: Reverse-order SWAR serial backends for 2-4 byte needles

[chiliec]

Closes #70.

Adds sz_rfind_2byte_serial_, sz_rfind_3byte_serial_, and sz_rfind_4byte_serial_, mirroring the forward SWAR kernels, and wires them into sz_rfind_serial in place of the TODO slots. Previously every 2..256-byte needle in reverse went through Horspool.

Each kernel walks backwards over 8 candidate offsets [last - 7, last] per iteration. It reuses the same sz_u64_each_{2,3,4}byte_equal_ masks and lane shifts as the forward versions, and picks the highest matching lane with 63 - clz instead of ctz. The big-endian fallback and the !SZ_USE_MISALIGNED_LOADS alignment tail follow the same structure as sz_rfind_byte_serial.

Validation (x86_64, GCC)

• cmake -D STRINGZILLA_BUILD_TEST=1 -D STRINGZILLA_USE_SANITIZERS=0 -D CMAKE_BUILD_TYPE=Release -B build_release && cmake --build build_release --target stringzilla_test_cpp20 → build_release/stringzilla_test_cpp20: All tests passed.
• Differential fuzz against a brute-force memcmp reverse search: 400k random cases covering haystack lengths 0..299, needle lengths 2..4, start offsets 0..15 (misaligned), small alphabets plus high-bit bytes. Checked both sz_rfind_serial and the dispatched sz_rfind, built with -fsanitize=address,undefined and SZ_USE_MISALIGNED_LOADS=0/1. 0 mismatches, no ASan reports.
• Micro-benchmark, sz_rfind_serial on a 1 MiB random haystack with no match, -O2:
  • 2-byte: 0.14 → 2.54 GB/s
  • 3-byte: 0.28 → 1.02 GB/s
  • 4-byte: 0.43 → 1.24 GB/s

Not tested: big-endian targets (that path is the plain byte loop) and non-x86 hardware.