[BugFix] Never raise a strict cast overflow error from a null row's data (backport #74903)

[mergify]

Why I'm doing:

A strict-mode numeric narrowing cast (the AllowThrowException path of UNARY_FN_CAST_VALID,
e.g. cast(x AS INT) when an overflow must error instead of becoming NULL) evaluated the overflow
check on every row of the input, including null rows. The data stored in a null row's slot
is undefined: when a producer leaves garbage there, the check sees an out-of-range value and throws
a spurious exception, failing a query that should succeed — the row is NULL and its value is
irrelevant.

What I'm doing:

• Add NullAwareInputCheckUnaryFunction (be/src/exprs/unary_function.h). For a nullable input it
  converts all rows but only treats a non-null row's overflow as an error; a null row's data
  can never be the cause of an exception. The hot loop stays branchless and vectorizable (convert
  every row, detect overflow with the non-throwing check AND-ed with the not-null mask and
  OR-accumulated); the throwing check runs only on a cold path entered when a genuine non-null row
  overflows.
• Wire the strict (AllowThrowException) branch of UNARY_FN_CAST_VALID to use it, passing the
  non-throwing NumberCheck for hot-loop detection and NumberCheckWithThrowException for the cold
  error path.

Bonus: the new implementation is ~1.4-1.6x faster than the old one across nullable/non-nullable
shapes — it avoids materializing and scanning a separate null-mask column and keeps the loop
vectorizable (no per-row branch, no throw in the hot path). Benchmark numbers are in the bench file.

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5

---

This is an automatic backport of pull request #74903 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 5847dd7 has failed:

On branch mergify/bp/branch-4.0/pr-74903
Your branch is up to date with 'origin/branch-4.0'.

You are currently cherry-picking commit 5847dd7825.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	new file:   be/src/bench/cast_overflow_check_bench.cpp
	modified:   be/src/exprs/cast_expr.cpp
	modified:   be/src/exprs/unary_function.h
	modified:   be/test/CMakeLists.txt
	new file:   be/test/exprs/unary_function_test.cpp
	new file:   test/sql/test_hive/R/test_hive_parquet_dict_null_cast
	new file:   test/sql/test_hive/T/test_hive_parquet_dict_null_cast

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   be/src/bench/CMakeLists.txt

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[mergify]

@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr