Epic: Simplify functions signature with LogicalType

### Is your feature request related to a problem or challenge?

Some functions signature is quite verbose, like

```rust
impl RegexpLikeFunc {
pub fn new() -> Self {
Self {
signature: Signature::one_of(
vec![
TypeSignature::Exact(vec![Utf8View, Utf8]),
TypeSignature::Exact(vec![Utf8View, Utf8View]),
TypeSignature::Exact(vec![Utf8View, LargeUtf8]),
TypeSignature::Exact(vec![Utf8, Utf8]),
TypeSignature::Exact(vec![Utf8, Utf8View]),
TypeSignature::Exact(vec![Utf8, LargeUtf8]),
TypeSignature::Exact(vec![LargeUtf8, Utf8]),
TypeSignature::Exact(vec![LargeUtf8, Utf8View]),
TypeSignature::Exact(vec![LargeUtf8, LargeUtf8]),
TypeSignature::Exact(vec![Utf8View, Utf8, Utf8]),
TypeSignature::Exact(vec![Utf8View, Utf8View, Utf8]),
TypeSignature::Exact(vec![Utf8View, LargeUtf8, Utf8]),
TypeSignature::Exact(vec![Utf8, Utf8, Utf8]),
TypeSignature::Exact(vec![Utf8, Utf8View, Utf8]),
TypeSignature::Exact(vec![Utf8, LargeUtf8, Utf8]),
TypeSignature::Exact(vec![LargeUtf8, Utf8, Utf8]),
TypeSignature::Exact(vec![LargeUtf8, Utf8View, Utf8]),
TypeSignature::Exact(vec![LargeUtf8, LargeUtf8, Utf8]),
],
Volatility::Immutable,
),
}
}
}

Can replace it with `Signature::string(2, Volatility::Immutable)`
```

```rust
impl LPadFunc {
pub fn new() -> Self {
use DataType::*;
Self {
signature: Signature::one_of(
vec![
Exact(vec![Utf8View, Int64]),
Exact(vec![Utf8View, Int64, Utf8View]),
Exact(vec![Utf8View, Int64, Utf8]),
Exact(vec![Utf8View, Int64, LargeUtf8]),
Exact(vec![Utf8, Int64]),
Exact(vec![Utf8, Int64, Utf8View]),
Exact(vec![Utf8, Int64, Utf8]),
Exact(vec![Utf8, Int64, LargeUtf8]),
Exact(vec![LargeUtf8, Int64]),
Exact(vec![LargeUtf8, Int64, Utf8View]),
Exact(vec![LargeUtf8, Int64, Utf8]),
Exact(vec![LargeUtf8, Int64, LargeUtf8]),
],
Volatility::Immutable,
),
}
}
}

Can replace it with one of `Signature::coercible(string, int)` and `Signature::coercible(string, int, string)`
```

### Describe the solution you'd like

#13240 starts an attempt to bring logical type to function signature

There are more functions to be cleanup.
The example above can be replaced with TypeSiganture::String, TypeSiganture::Numeric, TypeSiganture::Coercible.

We might also need time related signature for time function.

Improve test coverage with these functions especially with different kinds of types would be great 👍

### The role of TypeSignature
TypeSignature used in function which is responsible for handling
1. length check
2. type checking and casting

**The functions behaviour follows Postgres, DuckDB or other well-designed database. Can check whether the result and coercion is consistent with them**.

If the result is consistent in both Postgres, DuckDB, we should follow them. Otherwise, we follow either of them.

For the casting rule, I think we can follow DuckDB's casting rule described [here](https://duckdb.org/docs/sql/data_types/typecasting.html)

TypeSignature should handle *implicit casting*

> [Implicit Casting](https://duckdb.org/docs/sql/data_types/typecasting.html#implicit-casting)
In many situations, the system will add casts by itself. This is called implicit casting. This happens for example when a function is called with an argument that does not match the type of the function, but can be casted to the desired type.

> Consider the function sin(DOUBLE). This function takes as input argument a column of type DOUBLE, however, it can be called with an integer as well: sin(1). The integer is converted into a double before being passed to the sin function.

> Implicit casts can only be added for a number of type combinations, and is generally only possible when the cast cannot fail. For example, an implicit cast can be added from INTEGER to DOUBLE – but not from DOUBLE to INTEGER.

# Tasks
- [ ] https://github.com/apache/datafusion/issues/19004
- [ ] https://github.com/apache/datafusion/issues/12725
- [ ] https://github.com/apache/datafusion/issues/18685
- [ ] https://github.com/apache/datafusion/issues/14761
- [x] https://github.com/apache/datafusion/issues/13552
- [ ] https://github.com/apache/datafusion/issues/13285
- [ ] https://github.com/apache/datafusion/issues/13371
- [ ] https://github.com/apache/datafusion/issues/10507
- [ ] https://github.com/apache/datafusion/issues/7580
- [x] https://github.com/apache/datafusion/issues/7225
- [ ] https://github.com/apache/datafusion/issues/6559
- [ ] https://github.com/apache/datafusion/issues/15817
- [x] https://github.com/apache/datafusion/issues/18092
- [ ] https://github.com/apache/datafusion/issues/14760
- [ ] https://github.com/apache/datafusion/issues/14763
- [ ] https://github.com/apache/datafusion/issues/12698
- [x] https://github.com/apache/datafusion/issues/19438
- [ ] https://github.com/apache/datafusion/issues/19458
- [ ] https://github.com/apache/datafusion/issues/24133
- [x] https://github.com/apache/datafusion/issues/24135
- [ ] https://github.com/apache/datafusion/issues/24136
- [ ] https://github.com/apache/datafusion/issues/24141

Read #13240 and the Signature/TypeSignature definitions first; use the unchecked task links to choose a single function area and compare its behavior with Postgres or DuckDB. Done means the selected signatures use logical types, implicit casting behavior is covered by tests, and the result matches the chosen database behavior.

Written by the indexing model from the issue text.