bug#56596: 29.0.50; void-variable cl--nm

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> I can reproduce this -- but only when using dynamic binding.  When using
>> lexical binding, things work fine.

Indeed, `cl-defmethod` (and `cl-defgeneric`) aren't guaranteed to work in
dynbind code.  They often do, admittedly.

>> I've added Stefan to the CCs; perhaps he has some comments.
>
>   I suspect that cl-generic implementation has recently changed and that
>   it should not be used nowadays exactly like it has been. Any small
>   explanations from Stefan would be greatly appreciated !

The "next method" is not known when we compile `cl-defmethod` but it is
known when we build the "effective method", which is expected to be done
much less often than actual calls to that method.

The old code for `cl-defmethod` turned

    (cl-defmethod I ((d raw-daughter))
      (format "the daughter of %s"
              (cl-call-next-method)))

into something like

    (cl-..register (raw-daughter)
      (lambda (cnm d)
        (format "the daughter of %s"
                (apply cnm))))

forcing the caller to build a `cnm` closure which captures the args list
containing the value of the `d` argument.  Also it made it difficult to
implement `next-method-p` since that requires digging into this `cnm`
closure to see if it's one of those that would signal no-next-method.

The new code instead is a bit like:

    (cl-..register (raw-daughter)
      (lambda (nm)
        (lambda (&rest args)
          (let ((cnm (lambda (&rest cnmargs) (apply nm (or cnmargs args)))))
            (destructive-bind (d) args
              (format "the daughter of %s"
                      (apply cnm)))))))

This basically moves some of the code from the caller to here, which
doesn't seem to buy us very much but:
- it makes it much easier to implement `next-method-p` because now we
  have access to the actual "next method", rather than to a closure that
  combines the next methods with the saved arg list, so it's much easier
  to tell if the next method is the one that signals no-next-method.
- we occasionally get to skip building the `cnm` closure because we can
  use λ-lifting instead (basically the byte-compiler gets to see both
  parts of the code together and can thus change it: with this new code
  we could actually improve the code generated by the byte-compiler
  even further).

Problem is that the new code relies on the use of currying (see how
`nm` and `args` are now passed in a curried fashion), which is only
possible with lexical scoping.


        Stefan