perf: Optimize scalar fast path of to_hex function

[kumarUjjawal]

Which issue does this PR close?

• Part of [EPIC] Optimize performance for slow expressions datafusion-comet#2986

Rationale for this change

to_hex (used by benchmark items hex_int / hex_long) previously routed evaluation through make_scalar_function(..., vec![]), which converts scalar inputs into size‑1 arrays before execution. This adds avoidable overhead for constant folding / scalar evaluation.

What changes are included in this PR?

• Add match-based scalar fast path for integer scalars:
  • Int8/16/32/64 and UInt8/16/32/64
• Remove make_scalar_function(..., vec![]) usage

Type	Before	After	Speedup
to_hex/scalar_i32	270.73 ns	86.676 ns	3.12x
to_hex/scalar_i64	254.71 ns	89.254 ns	2.85x

Are these changes tested?

Yes

Are there any user-facing changes?

No

[comphead]

might be related #20044

[comphead]

we prob can make it reusable buffer?

[kumarUjjawal]

Thanks for the feedback. My initial thinking was the scalar fast path buffer is a fixed 16‑byte stack array, so it’s already very cheap and not heap-allocating. The array path is where buffer reuse matters and we already reuse a single buffer across the whole batch there. What do you think, should we still go ahead with the buffer reuse change?

[Jefffrey]

This function should be called only once per invocation so I don't think we need to change this to reuse a buffer. Looks like the array path already has a reusable buffer too

[comphead]

Thanks @kumarUjjawal I think this is great, however you can check if the reusable buffer can bring up more benefits

[Jefffrey]

This function should be called only once per invocation so I don't think we need to change this to reuse a buffer. Looks like the array path already has a reusable buffer too

[comphead]

Thanks @kumarUjjawal and @Jefffrey for the review