…d of `Exception e`

There's not much you can do with an `Exception e` anyway, so almost all
realistic uses of this function would have to do `fromException .
toException` to get something useful anyway

This is exactly what `updateFromOriginalException` was doing anyway, so
this change makes that more convenient too.

Unfortunately, this requires a major version bump, even though most
users will be using a higher-level function whose type has not changed.

Closes #80.

GHC-9.12 / base-4.20 introduces `ExceptionWithContext` as a way to read
backtraces off of functions like `error`. This means `ErrorCall` no
longer includes the information, which broke us.

To address this, we can `fromException` to that type, and then parse the
displaying of it. The format is similar but different to what
`ErrorCall` was, but we can re-use most of `errorCallParser` by
factoring out the stack-frame bits.

To keep things working on older GHC's we can put this behind CPP and
expose our own type and function of the same names, but with no-op
functionality.

Fixes #99.

We were doing that only for the `stack.yaml` job, but the setup now has
`stack.yaml` as a symlink to the latest LTS, and _not_ running CI for it
duplicatively. So instead we need to maintain the "default" job as the
latest LTS concretely.

I wonder if `generate-matrix` could put something else in the matrix to
identify where a given resolver sits in the set, that we could key on my
dynamically.