[DSLX] Show the parametric environment when type errors occur in a parametric instantiation

We instantiate parametrics in a demand driven fashion (instead of proving a parametric holds "for all x", we instantiate for concrete values of x at a given invocation site). For example:

```
fn id(x: uN[N]) -> uN[M] { x }
fn works() -> u32 { id(u32:42) }
fn broken() -> u64 { id(u32:42) }
```

Gives the following error:

```
/tmp/example.x:1:44-1:45
0001: fn id(x: uN[N]) -> uN[M] { x }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^ XlsTypeError: uN[32] vs uN[64]: Return type of function body for 'id' did not match the annotated return type.
0002: fn works() -> u32 { id(u32:42) }
0003: fn broken() -> u64 { id(u32:42) }
```

But there is no indication that the instantiation which "drove" the type error from `id` was `broken()` -- this bug is to add a backtrace that indicates where the instantiation was driven from. Note there can be multiple parametric instantiations nested inside of each other. Logging the parametric environment and perhaps the stack of parametric invocations driving the instantiation would both be useful indicators.

Start by tracing DSLX's parametric instantiation and type-error paths, using the id/works/broken example in the issue as the reproduction. The change is complete when errors identify the driving invocation, show its parametric environment, and account for nested parametric invocations.

Written by the indexing model from the issue text.