Adds WindowUDFImpl::reverse_exprtrait method + Support for IGNORE NULLS

[jcsherin]

Which issue does this PR close?

Part of #8709.
Closes #12661.

Rationale for this change

1. So that a user-defined window function can customize the implementation for evaluating results in reverse order, allowing the optimizer to avoid sorting the data.
2. Check if IGNORE NULLS is set.
3. Easier to review a smaller diff compared to a PR converting an existing built-in window function.

What changes are included in this PR?

1. Extends WindowUDFExpr with two new state fields for tracking if a window expression is reversed, and if IGNORE NULLS is used in the query.

/// Implements [`BuiltInWindowFunctionExpr`] for [`WindowUDF`]
#[derive(Clone, Debug)]
struct WindowUDFExpr {
    ...,
    /// This is set to `true` only if the user-defined window function
    /// expression supports evaluation in reverse order, and the
    /// evaluation order is reversed.
    is_reversed: bool,
    /// Set to `true` if `IGNORE NULLS` is defined, `false` otherwise.
    ignore_nulls: bool,
}

2. Adds a new trait method WindowUDFImpl::reverse_expr with a default implementation.

pub trait WindowUDFImpl: Debug + Send + Sync {

    /// Allows customizing the behavior of the user-defined window
    /// function when it is evaluated in reverse order.
    fn reverse_expr(&self) -> ReversedUDWF {
        ReversedUDWF::NotSupported
    }
}

pub enum ReversedUDWF {
    /// The result of evaluating the user-defined window function
    /// remains identical when reversed.
    Identical,
    /// A window function which does not support evaluating the result
    /// in reverse order.
    NotSupported,
    /// Customize the user-defined window function for evaluating the
    /// result in reverse order.
    Reversed(Arc<WindowUDF>),
}

3. Thread ignore_nulls when creating user-defined window expressions.

fn create_udwf_window_expr(
    fun: &Arc<WindowUDF>,
    args: &[Arc<dyn PhysicalExpr>],
    input_schema: &Schema,
    name: String,
    ignore_nulls: bool,  // <-- here
) -> Result<Arc<dyn BuiltInWindowFunctionExpr>> {
   ...
}

Are these changes tested?

Yes, against existing tests in CI.
No.

When built-in functions like lead, lag, nth_value etc. are converted, this API will get tested by existing sqllogictests.

Are there any user-facing changes?

Yes, this is a breaking API change: WindowUDFImpl::reverse_expr
No (default implementation provided for new trait method WindowUDFImpl::reverse_expr).

[alamb]

I love it -- thank you @jcsherin

One thing I noticed is that there are no tests for this functionality (as in if we removed / broke the code no tests would fail). Is the idea that it will be test coverage added when we port some of the built in window functions?

[alamb]

👍 -- this is a very nice API

[jcsherin]

One thing I noticed is that there are no tests for this functionality (as in if we removed / broke the code no tests would fail). Is the idea that it will be test coverage added when we port some of the built in window functions?

Yes, this situation is temporary. When one of the built-in window functions like lead, lag, nth_value etc. are converted this API path will get tested by existing sqllogictests.

[alamb]

Thank you @jcsherin -- the temporary nature of this code makes sense to me

[alamb]

given the newly added trait method returns a default value, I don't think this is a breaking API change

[jcsherin]

Got it 👍

[alamb]

Thank you @jcsherin