Behavior for from_items input should be completely defined

[gibson042]

See discussion in #102.

Behavior is currently undefined for from_items input that is not an array of [string, value] pairs. Examples:

1. items with length 0: from_items(`[ [] ]`)
2. items with length 1: from_items(`[ ["keyWithNoValue"] ]`)
3. items with length greater than 2: from_items(`[ ["key", "value", "extra"] ]`)
4. items indicating non-string keys: from_items(`[ [1, "number"], [null, "null"], [{}, "object"] ]`)

[springcomp]

I would argue:

• Input is expected to be an array of arrays, each of which has at least two values, the first being a string. If that is not the case, an error MUST be raised. The JMESPath.Net raises a new error type invalid-value but invalid-type would work equally well.
• Input can be an empty array, in which case, the result of from_items() is {} an empty object.

Therefore, examples 1, 2 and 4 raise an error.
Example 3 discards extra entries from each array and returns { "key": "value" }

A case can be made for example 3 to also raise an error.

[gibson042]

I agree on rejecting 1, 2, and 4, and have a minor preference for rejecting 3 as well (aligning with the general strict input validation throughout the language, such as sort rejecting mixed arrays).

[springcomp]

The more I think about this, the more I like the new invalid-value error type, here.

This could better apply to the $count parameter for split() and replace() as well for instance. When specifying a number, the syntax is correct and the type matches the signature. However, the function expects an integer.

What do you think?

[gibson042]

I'm in favor. 👍

[springcomp]

jmespath-community/jmespath.test#13

[springcomp]

#131