feat: Allow log with non-integer base on decimals

[Yuvraj-cyborg]

Which issue does this PR close?

Closes #19347

Rationale for this change

Native decimal log() (added in #17023) only supports integer bases. Non-integer bases like log(2.5, x) error out, which is a regression from the previous float-based implementation.

What changes are included in this PR?

Changes :

• Fallback to f64 computation when base is non-integer
• Integer bases (2, 10, etc.) still use efficient ilog() algorithm

Refactoring:

• Unified log_decimal32, log_decimal64, log_decimal128 into single generic log_decimal using num_traits::ToPrimitive.
• Used ToPrimitive::to_f64() and to_u128()
• Invalid bases (≤1, NaN, Inf) now return NaN instead of erroring - matches f64::log behavior
  Large Decimal256 values that don't fit in i128 now work via f64 fallback.

Are these changes tested?

Yes:

• All existing log_decimal* unit tests pass
• Updated test_log_decimal128_invalid_base - expects NaN instead of error
• Updated test_log_decimal256_large - now succeeds via fallback

Are there any user-facing changes?

Yes:

-- Previously errored, now works
SELECT log(2.5, 100::decimal(38,0));

-- Invalid base now returns NaN instead of error (consistent with float behavior)
SELECT log(-2, 64::decimal(38,0));  -- Returns NaN

[Yuvraj-cyborg]

cc: @Jefffrey @martin-g

[Yuvraj-cyborg]

cc: @alamb

[Jefffrey]

I think we need to check some of these other error conditions such as base being non-finite or base being less than 1.0, as I don't think they error on float version

[Yuvraj-cyborg]

check the recent changes
Using a single trait and unified the previous functions !

cc: @Jefffrey

[Jefffrey]

I'm not sure about this choice to universally convert to u128, even for decimal32 & decimal64

[Yuvraj-cyborg]

Valid ! It's overkill

[Jefffrey]

Could we move these tests to SLTs

[Yuvraj-cyborg]

cc: @Jefffrey

[Jefffrey]

I must admit I am very lost now; it seems this PR has removed all the logic for computing log natively on decimal and now we manually convert to float?

[Yuvraj-cyborg]

I must admit I am very lost now; it seems this PR has removed all the logic for computing log natively on decimal and now we manually convert to float?

Apologies ! I misunderstood your feedback about u128 and overcorrected by removing the native decimal logic entirely.
I'm fixing it rn

[Jefffrey]

Thanks @Yuvraj-cyborg