Support different scales for decimal binary math functions

[theirix]

Which issue does this PR close?

• Closes Improve scale support for binary decimal operations #19621.

Rationale for this change

A helper calculate_binary_math and UDFs relying on it could behave strangely if the scales of inputs and outputs are different. Original logic didn't fully handle it.

So let's introduce calculate_binary_math_decimal and calculate_binary_math_numeric functions with a proper handling of arguments of different scales and type casting for input and output arguments.

They supersede calculate_binary_math and calculate_binary_math_decimal because they have a slightly different functor signature that automatically passes the effective precision and scale (even if rescaled). The rest is compatible.

What changes are included in this PR?

• New functions
• Port existing UDFs to new functions

Are these changes tested?

• Existing unit tests
• SLTs

Are there any user-facing changes?

Older functions could be deprecated. Since they are a part of the public interface of datafusion-functions, I just placed a comment without a full-fledged deprecate macro. Up to discussion whether it should be used

[theirix]

Recent related changes: #18525 and #19384 . Epic #18889

[Jefffrey]

I'm having trouble understanding the rationale here; log, power and round at most have one decimal input, and only round preserves the decimal type whereas the others will return floats anyway. So all this handling for getting precision/scale of left/right inputs, adjusting the scale of the output decimal, seems unused?

Also for round we have a PR relating to altering precision/scale:

• fix: increase ROUND decimal precision to prevent overflow truncation #19926

[theirix]

I'm having trouble understanding the rationale here; log, power and round at most have one decimal input, and only round preserves the decimal type whereas the others will return floats anyway. So all this handling for getting precision/scale of left/right inputs, adjusting the scale of the output decimal, seems unused?

For most of these functions, agree, only one argument is decimal, so we execute the decimal/non-decimal case with code for adjusting both scales untouched.

Overall, I can see the following benefits:

• simplifying a caller code by duplicating non-obvious logic to this helper
• for decimal/non-decimal case, it performs casting of input and output types, so parameter scale is not lost when operating on a native type
• for decimal outputs, it removes the burden of setting the precision and scale on output
• for array cases, it is hard to write manual code of scaling to output type (not always a default Decimal(38,10)), so cast_array_to does it for the caller
• providing effective scale and precision of a type to the user-provided kernel without capturing it from arguments

So, symmetric functions like gcd/lcm (WIP), mod, div, etc benefit most from this PR.

From the first glance, a log function can be greatly simplified by dropping unscale_to_* calls in kernels and extra casting.

For pow, originally it was Dec x Float -> Dec, but since introducing a fallback to the float version from #19369 (still thinking when it is necessary), it is less relevant.

Also for round we have a PR relating to altering precision/scale:

* [fix: increase ROUND decimal precision to prevent overflow truncation #19926](https://github.com/apache/datafusion/pull/19926)

Yes, I discovered it recently. I am wondering whether it could also be simplified using this PR, since it handles different input and output precisions and scales.