bug#54802: OClosure: Make `interactive-form` a generic function

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

> My comment is that when you introduced OClosures, you never said that
> the plan was to go over every place in Emacs where they can be used
> and reimplement those places based on OClosures.

I don't understand the above because this patch doesn't make use
of OClosures.  Instead it adds a bit of flexibility to OClosures (the
ability to compute their `interactive-form`).

OT1H if I was given a chance to go back in time I probably would
define `lambda` as a macro that expands to a (trivial)
`oclosure-lambda` and then define `function-documentation` as a function
that simply extracts the `documentation` slot of its OClosure argument
(and same for `interactive-form`).

But given where we are I don't think this will happen and I don't think
my patches "go over every place in Emacs where [OClosures] can be used".

Instead, I see OClosures only used at a few places where they are
beneficial.  So far these places are: `kmacro.el`, `nadvice.el`,
and `cl-generic.el`.  The original motivation behind OClosures was
`nadvice.el`.

Currently on `master` we use OClosures in `cl-generic.el` and in
`kmacro.el`.  For `nadvice.el` there is one remaining hurdle which is
the handling of the interactive specs, i.e. the subject of this
bug report.

> All that to solve some minor issues with nadvice, which itself is
> a minor feature as Emacs features go?

That's the core question, yes (tho I think the improvements in
`kmacro.el` and the slight speed up of `cl-generic.el` are a nice side
effect for end users).


        Stefan