Bogus stack trace with MIR verification and wrong return type

[sauclovian-g]

I just accidentally wrote a spec with a wrong return type, and this fails with a stack trace. Now that the position tracking has been degarbled upstream of this, it's become clear that something else is wrong.

The example I'm working with is complicated and has lots of saw-script support code, so the stack trace is fairly substantial. This reveals that it's fairly off:

• The first entry is attributed to a function f, but located at the (top-level) call site of f.
• The second entry is attributed to a function g, but located in f. It's at the call site of g.
• Both the third and fourth entries are located in g, one attributed to and at the call site of mir_unsafe_assume_spec, the other attributed to the function passed to mir_unsafe_assume_spec and located at the partial closure in the mir_unsafe_assume_spec call site.
• The next two entries repeat the pattern of being at the call site of the function they're attributed to.
• The last entry is attributed to the same function as the second-last, but located within it.
• The mir_return that failed is never directly mentioned, although it's near the location of the second-last entry.

It appears that the positions and functions are misaligned, possibly with a bad zip or equivalent, but there's also something odd going on with closures, and what should probably be the last entry (the failing mir_return) is missing.

This wants a simpler test, or possibly two (one for the closure) but that probably won't be that difficult.