RFC: Make fields of ScalarUDF non pub

[alamb]

Which issue does this PR close?

Part of #7110 and #7977

Rationale for this change

Over time, the number of built in functions within DataFusion grows which is challenging both because:

1. The total footprint grows, even for those who don't need the specific functions
2. The desired semantics may be different (e.g. many of the built in functions in DataFusion mirror postgres behavior, but some users wish to mimic spark behavior
3. User defined functions are treated differently from built in functions in some ways (e.g. they can't have aliases)

If is for this reason I would like to move towards only having functions defined as ScalarUDFs This will ensure:

1. ScalarUDFs have access to all the same functionality as "built in " functions
2. No function specific code will escape the planning

What changes are included in this PR?

1. Make all fields of ScalarUDF private and add accessors.

Then we can add additional fields / trait impls as proposed by @2010YOUY01

Are these changes tested?

Covered by existing tests

[alamb]

If we like this API change, the same would need to be applied for https://docs.rs/datafusion/latest/datafusion/logical_expr/struct.WindowUDF.html and https://docs.rs/datafusion/latest/datafusion/logical_expr/struct.AggregateUDF.html

[alamb]

the key change in this PR is to remove pub

[alamb]

Rather than expose the underlying function pointer directly, I opted to handle the nuance of calling it here.

[2010YOUY01]

Thank you, I think it's a good idea.

Now for scalar functions there are two execution paths: BuitlinScalarFunction and ScalarUDF, this way we are moving towards using ScalarUDF as the unified path.

What do you think is a good implementation plan for the next step?
I was thinking about making a converter from BuiltinScalarFunction -> ScalarUDF first, and let all BuiltinScalarFunctions use ScalarUDF as the execution path. After that ScalarUDF should be extended to cover full functionalities, then the migrating step will be much easier

[alamb]

What do you think is a good implementation plan for the next step?

I was thinking one next step might be to try and port a few BuiltInFunctions to be ScalarUDFs (maybe the string functions or the crypto functions like MD5) -- specifically remove them from the BuiltInFunction enum and make sure all the tests still pass

I think that would force is to figure out How to register these functions with the FunctionRegistry by default, and other potential touchpoints there might be

I will try and write up some ideas later todya

[alamb]

Productionized in #8079