bug#51883: 29.0.50; Command to get accidentally deleted frames back

[Juri Linkov <juri@linkov.net>]

> But as for loading the package, the problem is more general in the sense
> that maybe we should refrain from loading the package just because
> a frame is deleted.
>
> So maybe we should change the code so the hook's function doesn't
> require loading `frameset.el`.  AFAICT fundamentally, the only function
> from `frameset.el` that it needs is `frameset-filter-params`, so maybe
> we should move some of that code to `frame.el`.
>
> To make up for it, maybe we can move some of the `undelete-frame` code
> to `frameset.el` since it can't be used without `frameset.el` anyway?
>
>>   . saving configurations of 16 deleted frames _by_default_ means we
>>     again impose on all users something that only some of them will use
>
> IIUC framesets are designed to be serializable so they shouldn't hold on
> to external data like buffers and windows, so such 16 elements should
> cost very little in terms of heap use.

OTOH, since framesets are designed to be serializable, isn't it
overkill to use framesets in the same session?  For example,
`clone-frame` doesn't use framesets, and the effect of `clone-frame`
should be the same as what `undelete-frame` does.  The difference
between them is that with `clone-frame` the original frame is not deleted.