Make Pancake exceptions more intuitive

The exception syntax added in #1450 has one particularly confusing property: the variable used to receive the exception payload is not binding. So code like this becomes possible to write:

```
exception ExampleException : 1;

fun f() { throw ExampleException 1; }

fun g() {
var 1 x = 0;
var 1 y = 0;
try
y = f()
catch ExampleException => x { // this is not a binding occurrence of x! it's the same x as is defined above
y = x + 1;
}
return x + y; // returns 3, where one might expect 2 if the outer x was shadowed
}
```

I propose to change the semantics of `Call` so that the variable in exception handler clauses becomes a binding occurrence.

The `wordLang` mechanism we target still works like above, so somewhere between `pan`, `crep` and `loop` the compiler can invent a fresh name for storing the exception and wrap it around the `Call`. I'm not sure where the best place to do this would be. Doing it in `pan_to_crep` probably means some headache with shapes, and doing it lower down means more languages need to have their semantics changed.

Start by reading the semantics of Call and exception handler clauses, then compare the pan, crep, and loop stages, especially pan_to_crep and the wordLang target. Determine where a fresh exception name can be introduced without changing wordLang's behavior; done means the handler variable is a binding occurrence while the translated exception handling remains correct.

Written by the indexing model from the issue text.