fix: Avoid overlay panic on valid Unicode input, Postgres compatibility

[neilconway]

Which issue does this PR close?

• Closes overlay panics on valid utf-8 input #22044.
• Closes overlay behavior inconsistent with Postgres / SQL spec #22045.

Rationale for this change

overlay mixed up character-based and byte-based indexing, which resulted in either panicking or returning incorrect results on multi-byte Unicode input. While looking at this, I also fixed a few places where overlay's behavior was inconsistent with Postgres and the SQL spec, refactored the code, and added a benchmark.

What changes are included in this PR?

• Fix panic or wrong results on multibyte Unicode input
• Align edge-case behavior with Postgres: start past end appends replacement after the full input, start <= 0 errors
• Refactored the code to reduce redundancy and clarify variable names
• Add SLT tests for Unicode input and behavior changes for Postgres compatibility
• Add benchmark, in advance of subsequent performance optimization work

Are these changes tested?

Yes, and new tests added.

Are there any user-facing changes?

Yes. The behavior of overlay has changed for multibyte Unicode inputs, as well as the edge cases enumerated above.

[kosiew]

@neilconway
Nice improvement overall. I just had one small performance suggestion around the four-argument overlay path.

[kosiew]

Small optimization idea: the four-argument path calls string.chars().count() to clamp len, but overlay_one ends up computing the character length again internally. Since overlay_one already handles lengths that extend past the end of the string, it might be simpler to pass len through directly or move the clamp logic into overlay_one so we avoid the extra Unicode scan per row.