Backtrace mode

[Gemini Lasswell]

Hi All,

I've finished everything I set out to add to Backtrace mode, and have
pushed it to scratch/backtrace-mode. Documentation, NEWS and tests are
all done, so please have a look at it and let me know if you find
anything that should be fixed before I merge it.

Notable changes:

- It's now possible to toggle both local variable display and printing
with 'print-circle' for the entire buffer instead of just the current
frame, using the C-u prefix with 'v' and '#' respectively.

- C functions in backtraces now get links to their source code. Links
are also created for the reading position of 'eval-buffer' and
'eval-region'.

- I've added a new function 'cl-print-to-string-with-limit' to
cl-print.el, which tries to get a printed representation to fit in a
specified number of characters using 'print-length' and 'print-level'.
Backtrace mode is using it and I plan to use it for results printing
in Edebug, the Lisp Debugger and ERT, hopefully putting an end to
performance problems caused by excessively long lines in those modes.

- You can now expand all the '...'s in a backtrace frame at once using
backtrace-expand-ellipses, bound to '.' and with the C-u prefix expand
them without putting a limit on the expansion.

- In Edebug backtraces, three new commands are available.
backtrace-goto-source, bound to 's', works on frames in
Edebug-instrumented code, which are marked with a '>' on the left side.
I've also added edebug-backtrace-show-instrumentation and
edebug-backtrace-hide-instrumentation, to show and hide Edebug's
functions in the backtrace.

- The function 'backtrace' now uses Backtrace mode's printing and is now
located in backtrace.el instead of subr.el. The functions
'backtrace-frame' and 'backtrace-frames' remain in subr.el so that
Backtrace mode doesn't have to be loaded for programmatic access to the
backtrace from Lisp.