Derive ScalarUDFImpl equality, hash from Eq, Hash traits

[findepi]

Follows similar change for WindowUDFImpl and AggregateUDFImpl, i.e.
the 8494a39 and b8bf7c5 commits.

Previously, the ScalarUDFImpl trait contained equals and
hash_value methods with contracts following the Eq and Hash
traits. However, the existence of default implementations of these
methods made it error-prone, with many functions (scalar, aggregate,
window) missing to customize the equals even though they ought to.
There is no fix to this that's not an API breaking change, so a breaking
change is warranted.

Removing the default implementations would be enough of a solution, but
at the cost of a lot of boilerplate needed in implementations.

Instead, this removes the methods from the trait, and reuses DynEq,
DynHash traits used previously only for physical expressions. This
allows for functions to provide their implementations using no more than
#[derive(PartialEq, Eq, Hash)] in a typical case.

• follows Derive WindowUDFImpl equality, hash from Eq, Hash traits #17081
• follows Derive AggregateUDFImpl equality, hash from Eq, Hash traits #17130
• fixesImplement PartialEq, Hash for all UDFs (ScalarUDFImpl) #16868
• fixesReplace ScalarUDFImpl::{equals,hash_value} with UdfHash, UdfEq traits #16871
• closes[EPIC] ScalarUDFImpl::equals default implementation is error-prone #16677

[findepi]

Here is the only non-mechanical change in this PR.

[findepi]

for reference, due to how DF functions are written, i used a different regex

\#\[derive\(Debug\)\](\n *(pub(\((super|crate)\))? )?struct \w+ \{\n( *name: String,\n)? *signature\: Signature\,\n( *aliases: Vec<String>,\n)? *\})

• still not perfect, eg some functions derive Clone (just because they can) and the pattern doesn't cater for this
• it's unlikely that downstream projects have fields such as name and aliases in their functions, so I didn't cater for these in the upgrade guide.

[alamb]

loogs good to me -- thanks @findepi and @timsaucer