Add support for debugging

[GoogleCodeExporter]

At least backtraces will be needed. This is a bit tricky since there is no such 
thing as a stack, but the continuation chains should be followable fairly 
easily in 99% of cases.

Original issue reported on code.google.com by aohelin on 5 Jan 2012 at 8:42

[GoogleCodeExporter]

Some ideas how to do this in practice:

> (start-debugging <breakpoints>) 
  - switch to a special thread scheduler as in profiling (to avoid having whatever is done here affect the speed of normal operation)
  - store a ff of code vectors on which to break
  - enter a simple mcp-style prompt on each call (?)
  - allow exiting the debugger from these or by 
> (stop-debugging)

Further ideas:
  - allow giving arbitrary hooks for breakpoints as in 
      > (start-debugging (break-on (/ _ ,zero?) (move-player ,invalid-move?) ...)
  - set a mcp-action to allow setting error behavior to automatic debugger startup

Original comment by aohelin on 5 Jan 2012 at 9:34

[GoogleCodeExporter]

Two things turned up in the first attempt:

 - shared code, which is a really nice feature, somewhat kills the usefulness of the traces, because especially continuation code fragments which are often shared don't have the name one would expect.
    + could be fixed by adding a --debug flag which enables things that may slow things down but give better debugging info, like disabling code sharing

 - the most common place for the continuation is correct way less frequently than originally assumed, so one could
    + separate continuations from functions (yuck!)
    + find a way to identify them better
      o likely relies on a bytecode disassembler...

Original comment by aohelin on 7 Jan 2012 at 7:41