Problems:
- When iterating over an empty string in a list comprehension, the
result is an empty string. This is a bug, it should be an error.
- When iterating over a non-empty string in a list comprehension, the
expected and unexpected types in the error message are swapped.
- Error messages mention "std.flatMap" when object/list comprehensions
would iterate over a value that is neither array nor string.
```
$ jsonnet --version
Jsonnet commandline interpreter (Go implementation) v0.21.0-rc2
$ jsonnet -e '[a for a in ""]'
""
$ jsonnet -e '[a for a in "b"]'
RUNTIME ERROR: Unexpected type array, expected string
<cmdline>:1:1-17
During evaluation
$ jsonnet -e '{[a]: 1 for a in 2}'
RUNTIME ERROR: std.flatMap second param must be array / string, got number
<cmdline>:1:1-20
<cmdline>:1:1-20
During evaluation
$ jsonnet -e '[a for a in 1]'
RUNTIME ERROR: std.flatMap second param must be array / string, got number
<cmdline>:1:1-15
During evaluation
```
FWIW, the C++ implementation does not have any of these problems. It
gives:
```
RUNTIME ERROR: In comprehension, can only iterate over array.
```
In the Go implementation comprehensions are desugared to a call to
std.flatMap which does accept a string in the "arr" parameter.
The fix: Desugar comprehensions to a call to a new hidden builtin which
only accepts arrays.
Fixes multiple issues with stack traces leading to missing
stack trace lines. Also, we no longer put builtin context
on the line which *calls* the builtin as if it was a part
of the builtin itself.
Code for stack trace handling was centralized. We no longer
need traceElement argument in ~every function. Now the stack
trace state is kept solely in the interpreter.
