runtime: Fix (call/cc) inside exception handler

This is a marginal case but it's assumed to work by R7RS and is used in
its example definition of (guard).

Previously we had GC references inside SchemeException. As a C++
exception SchemeException is constructed in a special exception memory
area which is not copied as part of (call/cc). This causes two issues:

1) The stack relocation code would attempt to relocate the cell ref
   range pointers from the SchemeException as if they were placed on the
   stack and promptly crash

2) If the above was worked around it was still possible for multiple
   continuations to point to the same active exception which would cause
   a double-rooting of its data and corrupt the GC state

Instead explicitly root the parts of the exception we care about on our
stack. This means each continuation has a unique copy of the exception
information as part of the stack. Instead of rethrowing the original
exception reconstruct a new one using the rooted information on our
stack. This isn't ideal as we'll lose the backtrace information in e.g.
GDB but it allows R7RS's (guard) to work correctly.

Additionally, add two new functional tests:

- Test explicitly capturing an exception handler's continuation and
  invoking it from outside the exception handler

- Test the full definition of (guard) from R7RS + errata. Llambda will
  likely get its own implementation of (guard) optimised to avoid
  (call/cc) but the R7RS version is a good test of exception and
  continuation support.