bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> An alist entry describes what should happen at the time a buffer is
> shown.  'debugger-bury-or-kill' describes what should happen when a
> buffer is unshown, something which may happen long after showing it.
> So we have to remember the thing to do at unshow time (probably in a
> window parameter) and make the unshow code aware of it when it runs.

I imagine a list of prev/next-buffers as the tab-bar:

[buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E]
prev-buffers          current-buffer      next-buffers

Using switch-to-buffer adds a new buffer after the current "tab", e.g.

[buffer-A] [buffer-B] [buffer-C] [new-buffer] [buffer-D] [buffer-E]
prev-buffers                  current-buffer           next-buffers

But displaying a temporary buffer could add a "tab" to the end of the
tab-bar, this means at the end of the list of next-buffers:

[buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
prev-buffers                                         current-buffer

After exiting from this temporary buffer, it could be kept in the
list of next-buffers:

[buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
prev-buffers          current-buffer                    next-buffers

Then returning to prev-buffers (e.g. with kill-buffer) will not visit
this temporary buffer.  But display-buffer-reuse-window could look for
a previously displayed buffer in the list of next buffers.

> That is we have to decide whether we make one entry dedicated to each
> buffer display function or make entries that apply to more than one
> such function.  We have the latter already for the 'side' entry and
> I'm not sure whether I like it because it's not always clear whether
> two action functions are mutually exclusive: Now hardly anyone would
> ever want to _facultatively_ display a buffer in a side window or an
> atomic window.  But when we want 'side' to refer to where a new window
> should be created or (re-)used I'm not entirely sure.  I know that
> 'display-buffer-below-selected' and 'display-buffer-at-bottom' both
> implicitly fix the side (or direction) for both, using and splitting,
> and that's OK but maybe not all applications might want it.

We could have a general shorter name like 'dir', and more specific
longer names like 'select-dir' and 'split-dir'.  If no long entries
are found, then fall back to a shorter name.