Co-locate function parameter names and types with Signature::with_parameters

[kosiew]

Which issue does this PR close?

• Closes More ergnomic way to specify (named) paramters in signature #18685.

---

Rationale for this change

Function signatures in DataFusion currently define parameter types/coercions and parameter names in separate places (e.g. TypeSignature::Coercible(...) plus a later .with_parameter_names(...)). This separation makes signatures harder to read and increases the risk of names and types getting out of sync during maintenance.

This PR introduces an ergonomic builder API that lets authors define parameter names together with their expected DataType or Coercion rules in one place, improving readability and reducing duplication.

---

What changes are included in this PR?

• Added a new helper enum ParameterKind to represent either:

  • a concrete DataType (for TypeSignature::Exact and TypeSignature::Uniform), or
  • a Coercion rule (for TypeSignature::Coercible).

• Added Signature::with_parameter(...) and Signature::with_parameters(...) builder methods to:

  • store parameter names on the signature,

  • validate arity consistently via existing validation,

  • populate the underlying TypeSignature where applicable:

    • Exact: fills/overwrites the type list (with arity checks when already set)
    • Coercible: fills/overwrites coercion rules (with arity checks when already set)
    • Uniform: validates that provided types are among the allowed types and validates arity

  • reject unsupported cases (e.g. variable arity signatures) via existing validation.

• Refactored unicode::substr signature construction to use .with_parameters(&[...]), co-locating parameter names with their coercion rules.

• Added unit tests covering:

  • Exact, Coercible, and Uniform usage
  • mismatched arity errors
  • duplicate parameter name validation
  • variadic signature rejection

---

Are these changes tested?

Yes.

• Added new unit tests in signature.rs validating correct behavior and error cases for with_parameters.
• Existing tests continue to cover signature validation behavior, and the substr refactor is a mechanical adoption of the new API.

---

Are there any user-facing changes?

No user-facing behavior changes are intended.

This is a developer-facing refactor / ergonomics improvement for defining function signatures. Function semantics and runtime behavior should remain the same.

Note: There is a small public API surface addition (Signature::with_parameter(s) and ParameterKind). This should be non-breaking and additive.

---

LLM-generated code disclosure

This PR includes LLM-generated code and comments. All LLM-generated content has been manually reviewed and tested.