hclsyntax: Don't panic when function returns invalid ArgError

[apparentlymart]

When a function returns a functions.ArgError it's supposed to set the argument index to a valid index within the range of the given argument slice.

However, we typically try to be robust in the face of incorrectly-implemented functions, so rather than panicking in that case
as we would've before we'll now return a slightly-less-precise error message.

The if i > len(e.Args)-1 case in the previous code here was actually trying to handle this situation before, but it didn't quite manage to do it because it was incorrectly referring to e.Args rather than args (so it couldn't take into account expanded arguments) and because it incorrectly assumed that there would always be more declared parameters than arguments (which is only true when there's a variadic parameter that has no arguments at all in the call).

Now we'll handle out of range a little differently for variadic vs. non-variadic functions. For variadics we'll assume that the function was trying to talk about the variadic parameter and name that in the error message. For non-variadics we can't do anything special so we end up just treating it the same as any other error type, simply stating that the function call failed without naming a particular argument.

Functions that end up in this error-handling codepath should still be fixed, because they'll likely end up returning a slightly confusing error message which doesn't accurately reflect the source of the problem. The goal here is just avoid a panic in that case.

---

This originally surfaced in hashicorp/waypoint#1675. The root cause of that crash is that Waypoint's templatefile incorrectly reports an error in its vars argument even in situations where that argument isn't specified in the call. This change should make it stop panicking, but it'd also be good to update Waypoint to properly handle the situation where there is no vars but yet the template still refers to variables.

[mitchellh]

Thanks!