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

[martin rudalics]

> 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