bug#8911: bs-cycle-next deletes window in some cases.

[martin rudalics <rudalics@gmx.at>]

 > With current trunk.
 >
 >   emacs -Q -l bs
 >   C-x 2
 >   M-x bs-cycle-next <RET>
 >
 > and the bottom window is deleted.

IIUC this happens because of this code

	(unless (window-dedicated-p (selected-window))
	  ;; We don't want the frame iconified if the only window in the frame
	  ;; happens to be dedicated; let's get the error from switch-to-buffer
	  (bury-buffer))
	(switch-to-buffer next)

in `bs-cycle-next' and `bury-buffer' can now delete a window showing the
buffer provided this buffer was the first to appear in a window.

`bs-cycle-next' is probably not to blame because it just wants to make
sure that the buffer is not chosen again soon for displaying it.  So we
have a number of ways to restore the old behavior, namely

- have `bs-cycle-next' call `unrecord-buffer' instead of `bury-buffer',

- have `bury-buffer' only delete dedicated windows as before,

- give `bury-buffer' an extra argument which allows (or forbids) to
   delete the selected window (or corresponding frame),

- make sure that `bury-buffer' deletes only automatically created
   windows (much like the recent option `frame-auto-delete').

Personally, I have no preference since I never understood the
"additional" semantics of `bury-buffer'.  Earlier versions of this used
to iconify frames which some people on this list disliked severely so I
removed it.  So far no one missed this issue, but maybe I shall restore
it as well?

martin