Add PartitionEvaluatorArgs to WindowUDFImpl::partition_evaluator

[jcsherin]

Which issue does this PR close?

Closes #12803.

Rationale for this change

In BuiltInWindowFunction::{Lead, Lag} to create an instance of PartitionEvaluator directly/indirectly depends on the following being available:

1. arguments to the window function expression,
2. the data type of the arguments,
3. whether IGNORE NULLS is specified,
4. whether the execution order is reversed.

Currently none of this is available when implementing user-defined window functions.

What changes are included in this PR?

1. Add PartitionEvaluatorArgs to WindowUDFImpl::partition_evaulator.

pub trait WindowUDFImpl: Debug + Send + Sync {

    /// Invoke the function, returning the [`PartitionEvaluator`] instance
    fn partition_evaluator(
        &self,
        partition_evaluator_args: PartitionEvaluatorArgs,
    ) -> Result<Box<dyn PartitionEvaluator>>;

}

2. Defines PartitionEvaluatorArgs:

/// Defines the state of the user-defined window function during
/// physical execution.
#[derive(Debug, Default)]
pub struct PartitionEvaluatorArgs<'a> {
    /// The expressions passed as arguments to the user-defined window
    /// function.
    input_exprs: &'a [Arc<dyn PhysicalExpr>],
    /// The corresponding data types of expressions passed as arguments
    /// to the user-defined window function.
    input_types: &'a [DataType],
    /// Set to `true` if the user-defined window function is reversed.
    is_reversed: bool,
    /// Set to `true` if `IGNORE NULLS` is specified.
    ignore_nulls: bool,
}

Are these changes tested?

Yes. Updated unit tests for row_number() user-defined window function.

Are there any user-facing changes?

Yes.

[alamb]

Thank you @jcsherin -- this PR makes sense to me

I had a small API suggestions (but I also think we could do it as a follow on PR)

Also, I think this PR is an API change (for the better) so I added the api-change label

[alamb]

This description doesn't quite match what I think the structure does. Perhaps something like this would be more appropriate

Suggested change

	/// Defines the state of the user-defined window function during
	/// physical execution.
	/// Arguments passed to create user-defined window function state during
	/// physical execution.

[jcsherin]

Done.

[alamb]

I think an API that would be more consistent with others in this would be to expose the input_exprs directly.

Among other things that would allow users of this API to find out how many (len()) were passed as well as get an iterator, etc.

    /// Returns the arguments passed to the function
    pub fn input_exprs(&self) -> &'a [Arc<dyn PhysicalExpr>] {
        self.input_exprs
    }

[jcsherin]

Agreed.

I extended the change to also expose input_types directly for similar reasons.

    /// Returns the expressions passed as arguments to the user-defined
    /// window function.
    pub fn input_exprs(&self) -> &'a [Arc<dyn PhysicalExpr>] {
        self.input_exprs
    }

    /// Returns the [`DataType`]s corresponding to the input expressions
    /// to the user-defined window function.
    pub fn input_types(&self) -> &'a [DataType] {
        self.input_types
    }

[alamb]

I think this is the key reason to add these args

[alamb]

Thanks again @jcsherin

[jcsherin]

Thanks for the review @alamb