Optimize strpos() for ASCII inputs

[neilconway]

Is your feature request related to a problem or challenge?

strpos() in DataFusion is roughly 1.8x slower than in DuckDB in the string microbenchmark here.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

[neilconway]

take

[neilconway]

• The previous ASCII fastpath avoids string::find because it is slow. Indeed, it is -- but it is mainly slow because it has a lot of per-call overhead. The previous fast-path algorithm (slide a window using [T]::windows and check each window for an exact match) doesn't have per-call overhead but the algorithm itself is slow.
• memchr::memchr is considerably faster because of SIMD and other chicanery. It also has very low per-call overhead (unlike string::find or memmem::find).

Possible Further Improvements

• For the common case that the needle is a scalar, we could explore building a memmem::Finder for the needle once and then applying it to the haystack.
• For UTF inputs, we could still use memchr or a similar byte-based search, but once we find a match, we'd need to iterate over char_indexes to find the right character (not byte) offset. This would be a clear win when the needle isn't found in the haystack, but the net performance change for successful matches would be less clear.
• We decide whether to use the ASCII fast-path on a per-UDF-call basis (so potentially on an entire batch of haystack). For haystacks where some values are ASCII-only and some are not, doing this check on a per-row basis might be worthwhile.