bug#32825: 27.0.50; Deterministic window management

[Juri Linkov <juri@linkov.net>]

>> *Edebug Backtrace* should be treated exactly the same way as
>> *Backtrace*, but in practice this means adding a whole bunch
>> of same variables
>>
>> debugger-previous-window
>> debugger-pre-previous-window
>> debugger-previous-window-height
>> ...
>>
>> to edebug.el
>>
>> edebugger-previous-window
>> edebugger-pre-previous-window
>> edebugger-previous-window-height
>> ...
>>
>> and duplicating all related code.  This doesn't look right.
>>
>> I think that either we should generalize display-buffer-in-previous-window
>> to avoid such duplication, or better never display temporary buffers
>> in unrelated windows at all, i.e. to replace display-buffer-in-previous-window
>> in the action list with display-buffer-below-selected and
>> display-buffer-at-bottom.
>
> Pardon me, aren't you confusing 'display-buffer-in-previous-window'
> with 'switch-to-prev-buffer' here?  The change I propose doesn't
> affect 'display-buffer-in-previous-window' at all.  It simply should
> avoid that 'switch-to-prev-buffer' shows such a buffer.  Also, while
> 'display-buffer-below-selected' and 'display-buffer-at-bottom' usually
> do what they are intended to do they may also reuse an existing window
> when splitting fails.

'display-buffer-in-previous-window' searches the buffer in the
prev-buffers list that 'switch-to-prev-buffer' might want to skip
(I still doubt this need).

I proposed to generalize display-buffer-in-previous-window
to avoid duplicating code like in debug.el that uses
debugger-previous-window, debugger-pre-previous-window,
debugger-previous-window-height because the same feature
is needed in other packages like edebug.el.

The same feature is needed also for next-error to display hits
from different buffers in the same window.

Or better to obviate the need in all this complex special handling
simply by removing the get-lru-window rule in the default action,
thus replacing it with get-mru-window.