Introduce Signature::Coercible

[jayzhan211]

Which issue does this PR close?

Part of #10507

Rationale for this change

We can see that in DuckDB, they return float type for avg even the input type is not float.

D select stddev(cast(2 as decimal(3)));
┌─────────────────────────────────┐
│ stddev(CAST(2 AS DECIMAL(3,0))) │
│ double │
├─────────────────────────────────┤
│ │
└─────────────────────────────────┘
D select stddev(2);
┌───────────┐
│ stddev(2) │
│ double │
├───────────┤
│ │
└───────────┘

We return Integer in Datafusion. I think return Float for integer input has little downside but could make the type handling a lot simpler, since we have less types to care about.

What changes are included in this PR?

Add Signature::float that we accept type that is coercible to f64.

Are these changes tested?

Are there any user-facing changes?

[alamb]

Looks good to me -- thank you @jayzhan211

[alamb]

One minor comment is perhaps we should call this Float64 to be explicit that the argument will be 64 bit (rather than maybe f32 or maybe f64)

[jayzhan211]

I'm concern that we will ends up with specific signature Float32, Float64, Float16... Another idea I'm working on is introducing TypeSignature::Coercible(Vec<DataType>), similar to Exact but try to coerce to target type.

So we could have TypeSignature::Coercible(vec![Float64]) in this case, and this is a more general signature

[alamb]

Suggested change

	// Numreic and Coercible signature is validated in `get_valid_types`
	// Numeric and Coercible signature is validated in `get_valid_types`

[alamb]

perhaps we could add some comments here explaining what Coercible meant? Maybe it means that the input arguments can be coerced to one of the target types (in order)?

[alamb]

Reading this again, I am not sure how this is different than Exact(Vec<DataType>) as I thought the coercion logic would try to coerce the arguments to the types in Exact 🤔

Is the difference is that the input isn't actually converted to the Coercable types by DataFusion, but instead the function's implementation handles coercion internally?

[alamb]

This idea looks much nicer and general @jayzhan211