Better variadic type support

[Adam-Alani]

In inconsistent parameter context:

Each argument can be any possible concrete type afforded by the bounds
of any parameter defined in the arguments specification.

For example:

urn: "urn:example:extension"
scalar_functions:
  - name: "inconsistent_sum"
    impls:
      - args:
          - value: "decimal<P,S>"
            variadic:
              min: 1
              parameterConsistency: INCONSISTENT
        return: "decimal<38,S>"

This means that the following are valid:

inconsistent_sum(decimal<10, 2>, decimal<10, 2>, decimal<10, 2>)
inconsistent_sum(decimal<10, 2>, decimal<10, 2>)
inconsistent_sum(decimal<15, 8>, decimal<11, 8>, decimal<119, 8>)

On the other hand, the following are all invalid:

inconsistent_sum(decimal<10, 2>, decimal<10, 3>, decimal<10, 4>)
inconsistent_sum(decimal<10, 2>, i32)

The above example is showing that there is the implicit constraint across the variadic parameters that the scale S must be the same as the output (and thus must all be the same across the variadic parameter). On the other hand, the precision P is free to be anything. But all of the parameters do have to be decimal.

[benbellick]

#624 will introduce comments like:

/**
   * Validates that variadic arguments satisfy the parameter consistency requirement. When
   * CONSISTENT, all variadic arguments must have the same type (ignoring nullability). When
   * INCONSISTENT, arguments can have different types.
   */

For this ticket, we will want to make sure that we clarify the meaning of different types, e.g.

/**
   * Validates that variadic arguments satisfy the parameter consistency requirement. When
   * CONSISTENT, all variadic arguments must have the same type (ignoring nullability). When
   * INCONSISTENT, arguments can have different types, provided they satisfy the implied type constraints. 
   */