*DEBUGGER-HOOK* can now be set at the top-level

[rssoc]

This fixes a confusing interaction between *DEBUGGER-HOOK* and Slynk's dynamic-extent.

Example:

(let ((next-debugger-hook *debugger-hook*))
  (defun debugger-hook/test (condition me)
    (declare (ignore me))
    (let ((*debugger-hook* next-debugger-hook))
      (format t "yippee!")
      (invoke-debugger condition))))

Before this PR, trying to replace the *DEBUGGER-HOOK* with DEBUGGER-HOOK/TEST would be ineffective at the top-level:

CL-USER> (setq *debugger-hook* 'debugger-hook/test)
DEBUGGER-HOOK/TEST
CL-USER> *debugger-hook*
#<FUNCTION (LAMBDA (CONDITION SLYNK-MREPL::HOOK) :IN SLYNK-MREPL::MREPL-EVAL) {1002755D4B}>

With this PR, it works as expected:

CL-USER> (setq *debugger-hook* 'debugger-hook/test)
DEBUGGER-HOOK/TEST
CL-USER> *debugger-hook*
DEBUGGER-HOOK/TEST
CL-USER> (clearly bad form)
; in: CLEARLY BAD
;     (CLEARLY BAD FORM)
; 
; caught WARNING:
;   undefined variable: COMMON-LISP-USER::BAD
; 
; caught STYLE-WARNING:
;   undefined function: COMMON-LISP-USER::CLEARLY
; 
; caught WARNING:
;   undefined variable: COMMON-LISP-USER::FORM
;
; ...
yippee!
; Debugger entered on #<UNBOUND-VARIABLE BAD {1002D47D73}>

The fix is straightforward as an EVAL-FOR-EMACS wrapper function, so to see the effect in the REPL, I made MREPL-EVAL honor *EVAL-FOR-EMACS-WRAPPERS*. This makes a whole lot of sense to me.

[rssoc]

The original culprit is SLIME's CALL-WITH-DEBUGGER-HOOK which calls functions (eventually EVAL) with the top-level *DEBUGGER-HOOK* shadowed.

So the same issue is manifested in SLIME when doing in-buffer evaluations but not in the REPL, as their REP loop doesn't use CALL-WITH-DEBUGGER-HOOK or otherwise touch the *DEBUGGER-HOOK* (unlike SLYNK-MREPL).