Refactor: Unify Expr::ScalarFunction and Expr::ScalarUDF, introduce unresolved functions by name

[2010YOUY01]

Which issue does this PR close?

Part of #8157

Rationale for this change

See #8157 for the rationale:
Creation of Exprs for BuiltinScalarFunctions can be done statelessly

let expr1 = abs(lit(-1));
let expr2 = call_fn("abs", vec![lit(-1)]);

However, we can't do that for ScalarUDFs because they are registered within SessionState, it's only possible to do

let ctx = create_context()?;
ctx.register_udf(abs_impl);
let expr2 = ctx.call_fn("abs", vec![lit(-1)]);

For the ongoing plan to migrate functions from BuiltinScalarFunction to ScalarUDF based implementation (ref #8045 ), we would like the ScalarUDF based functions to continue to support the original Expr construction API, so the Expr struct should have a variant for unresolved name, and then we can add a AnalyzerRule to resolve the function.
This PR only include refactor preparation for UDF Expr support.

What changes are included in this PR?

1. Change Expr::ScalarFunction

// before
pub struct ScalarFunction {
    /// The function
    pub fun: built_in_function::BuiltinScalarFunction,
    /// List of expressions to feed to the functions as arguments
    pub args: Vec<Expr>,
}
// This PR
#[derive(Debug, Clone, PartialEq, Eq, Hash)]
pub enum ScalarFunctionDefinition {
    /// Resolved to a `BuiltinScalarFunction`
    /// There is plan to migrate `BuiltinScalarFunction` to UDF-based implementation (issue#8045)
    /// This variant is planned to be removed in long term
    BuiltIn(built_in_function::BuiltinScalarFunction),
    /// Resolved to a user defined function
    UDF(Arc<crate::ScalarUDF>),
    /// A scalar function constructed with name, could be resolved with registered functions during
    /// analyzing.
    Name(Arc<str>),
}

/// ScalarFunction expression invokes a built-in scalar function
#[derive(Clone, PartialEq, Eq, Hash, Debug)]
pub struct ScalarFunction {
    /// The function
    pub func_def: ScalarFunctionDefinition,
    /// List of expressions to feed to the functions as arguments
    pub args: Vec<Expr>,
}

2. Remove Expr::ScalarUDF

This way we can support unresolved function name variant.
Also, merge the execution path for BuiltinScalarFunction/ScalarUDF, to make future work towards #8045 a bit easier

Are these changes tested?

Covered by existing tests.

Are there any user-facing changes?

Yes, see comments for API changes

[2010YOUY01]

This is the major change

[2010YOUY01]

This is the major change

[alamb]

Thank you @2010YOUY01 -- I think this looks great 🦾 . I had a few small comments, but otherwise I think it is ready to go.

I want to leave this PR open for a few days to allow people a chance to comment

then we can add a AnalyzerRule to resolve the function.
This PR only include refactor preparation for UDF Expr support.

While waiting, it might help to create another draft PR on top of this one that implements name resolution so people can see how that would work

Some other todos (for myself):

1. File a ticket to do the same thing for AggregateUDF and WindowUDF (to maintain a consistent interface)

[alamb]

I think it is probably ok to support tree walks on unresolved function names. I don't see any reason to throw an error

[2010YOUY01]

Yes, I believe it's necessary, but I'm not sure how it will be implemented right now, so I plan to leave this change to next PR which resolves function Expr name

[2010YOUY01]

@alamb Thank you! Review comments are addressed

[alamb]

Thanks @2010YOUY01 -- I had one comment on name() signature but I also think we can do that as a follow on PR. As a reminder I want to leave this open a few more days to allow for comment prior to merging

[alamb]

I think it would be better to allow the callsites to decide if they needed to make the string copy -- so passing back &str I think would make for a better API:

Suggested change

	pub fn name(&self) -> String {
	pub fn name(&self) -> &str {

[alamb]

for example, this callsite doesn't need an owned String, &str would work well

[alamb]

Looks great -- thanks again @2010YOUY01