fix: round_even for floats for the single argument case

[tarekakrout2021]

Which issue does this PR close?

• Closes PostgreSQL compatibility: round(float8) should match PostgreSQL half-tie behavior #22269.

Rationale for this change

round(float8) should match PostgreSQL half-tie behavior (banker's rounding / round-half-to-even).

What changes are included in this PR?

• Changed round_float() to use round-half-to-even (ties-to-even) for the
  zero-decimal / single-argument case only
• The two-argument form is intentionally unchanged, as PostgreSQL does not
  support round(double precision, int) — that form operates on numeric types
• Added regression tests for f32 and f64 with canonical half-tie values
  (2.5, 3.5, -2.5, -3.5)
• Updated scalar.slt expected output to reflect the corrected behavior

Are these changes tested?

Ran:
cargo test --package datafusion-functions round
and

cargo test -p datafusion --test parquet_integration
cargo test --profile=ci --test sqllogictests

Are there any user-facing changes?

Yes — round(x) where x is a float and x is a half-tie value (e.g. 0.5, 1.5, 2.5)
will now return a different result. This is a correctness fix to match PostgreSQL behavior.

To run the CI : @kumarUjjawal

[kumarUjjawal]

Thank you @tarekakrout2021 for working on this, I think we are having a discussion about whether we should opt for PG compatibility just to follow one engine over another, since DuckDb already has the same behavior as Datafusion and it's not the case of one is wrong and the other is right. I think we should keep current behavior unless there is a strong reason to change it.

Let's keep the PR open for more discussion.

[tarekakrout2021]

That makes sense, thanks for taking the time to review this @kumarUjjawal .

If the direction shifts toward exposing a separate round_even function (similar to DuckDB), I’d be happy to implement it.