Simplify nvl2 implementation & fix coercion behaviour

[Jefffrey]

Which issue does this PR close?

• Closes Minor issue with nvl2_func #9479

Rationale for this change

Refactor the implementation to simplify it, and also fix which types we coerce.

What changes are included in this PR?

When coercing input types, we ignore the 1st argument (it is only used to calculate if return 2nd or 3rd argument so no need to consider it for coercion). Also simplify the actual implementation.

Are these changes tested?

Existing tests.

Are there any user-facing changes?

No.

[Jefffrey]

Maybe this becomes unnecessary if it'll get rewritten by #17983 anyway 🤔

[pepijnve]

I was planning on doing the same simplification as in #17982 where nvl2(x, y, z) would get simplified to case when x is not null then y else z end. The rationale is to try to make the various lazy, conditional logic variants (nvl, nvl2, coalesce) all aliases of CaseExpr so that we only have to optimise it once.

[Jefffrey]

I was planning on doing the same simplification as in #17982 where nvl2(x, y, z) would get simplified to case when x is not null then y else z end. The rationale is to try to make the various lazy, conditional logic variants (nvl, nvl2, coalesce) all aliases of CaseExpr so that we only have to optimise it once.

Sounds good, I'll close this PR and close the refactor issue as unplanned

Also fyi @kosiew since I see you self-assigned #17983