bug#71386: 29.1; Frame is auto-deleted even when it has multiple tabs

[martin rudalics]

> So the obstacle is that tab-bar-close-tab closes tabs only on the
> selected frame?  I don't know, this never was a problem.

For example, 'quit-windows-on' has to deal with all windows showing a
specific buffer on all frames specified by the FRAME argument, killing
that buffer if KILL is non-nil.  If any such window was created by the
tab-bar code, that is, its second 'quit-restore' element equals 'tab',
'tab-bar-close-tab' has to take care of that window by deleting it or
showing some other buffer in it.

If 'tab-bar-close-tab' doesn't do that, 'kill-buffer' will kick in and
replace that window's buffer by some arbitrary other buffer.  If, as we
currently test with my other patch, 'replace-buffer-in-windows' calls
'quit-restore-window' and the buffer is again not replaced, then
'kill-buffer' will fall back on replace_buffer_in_windows_safely which
doesn't care about the 'quit-restore' parameter and puts some arbitrary
buffer in that window.

Now 'quit-windows-on' is already broken because when KILL is non-nil,
the buffer gets killed in the first call of 'quit-restore-window' which
means to call 'replace-buffer-in-windows' on it which on trunk deletes
windows only if they are dedicated.  This is probably not in the sense
of the caller but so far nobody protested.  In either case we have to
fix this eventually including the leak that results when 'quit-restore'
parameters reference dead buffers.  When we do that, the tab-bar
function called by 'quit-restore-window' should be prepared to handle
the scenario sketched above.

martin