perf: optimize trim functions to reuse pattern buffer

[viirya]

Which issue does this PR close?

• Closes #.

Rationale for this change

What changes are included in this PR?

Replace per-row Vec allocation with a reusable buffer in trim functions (ltrim, rtrim, btrim).

The previous implementation allocated a Vec for the pattern on every row, which was inefficient. This optimization introduces a pattern_buf that is allocated once and reused across all rows by clearing and refilling it.

Changes:

• Refactored general_trim to pass TrimType directly instead of closures
• Created apply_trim helper function that accepts a mutable pattern buffer
• Updated string_view_trim and string_trim to allocate pattern_buf once
• Buffer is cleared and reused for each row to avoid repeated allocations

Benchmark results for ltrim (size=1024):

• INPUT LEN <= 12, string_view: 21.484 µs -> 13.243 µs (38.4% faster, 1.6x speedup)
• INPUT LEN <= 12, string: 21.540 µs -> 14.051 µs (34.8% faster, 1.5x speedup)
• INPUT LEN > 12, OUTPUT LEN > 12, string_view: 21.951 µs -> 13.325 µs (39.3% faster, 1.6x speedup)
• INPUT LEN > 12, OUTPUT LEN > 12, string: 24.328 µs -> 16.844 µs (30.8% faster, 1.4x speedup)
• INPUT LEN > 12, OUTPUT LEN <= 12, string_view: 87.967 µs -> 77.016 µs (12.4% faster)

Benchmark results for ltrim (size=4096):

• INPUT LEN <= 12, string_view: 85.626 µs -> 51.478 µs (39.9% faster, 1.7x speedup)
• INPUT LEN <= 12, string: 84.011 µs -> 54.774 µs (34.8% faster, 1.5x speedup)
• INPUT LEN > 12, OUTPUT LEN > 12, string_view: 85.964 µs -> 51.825 µs (39.7% faster, 1.7x speedup)
• INPUT LEN > 12, OUTPUT LEN > 12, string: 102.42 µs -> 74.097 µs (27.7% faster, 1.4x speedup)

The optimization shows consistent 28-40% improvement across most workloads by eliminating per-row Vec allocations. This applies to all trim variants (ltrim, rtrim, btrim) as they share the same underlying implementation.

Are these changes tested?

Are there any user-facing changes?