Hello - this is a draft for discussion rather than a finished proposal; please
say if the approach is wrong and I will change it or drop it.

Problem

A tiled pane always has a cell reserved for the separator between it and its
neighbour, so a one row pane used as a bar above or below another pane costs
two rows rather than one.

There is currently no way to get that cell back:

• pane-border-lines spaces and pane-border-format change what is drawn in
  the separator, not that it is there.
• pane-border-status adds a line rather than removing one.
• The border geometry is fixed in the layout.

Drawing the bar with a status format instead of a real pane is not always an
option, because a real pane keeps copy mode, mouse selection and drag to copy.

What this adds

pane-border-collapse, a choice option (off | top | bottom | left |
right | all) with window and pane scope, default off, so nothing changes
unless it is set.

It names the side of a pane that should be drawn over the separator on it
instead of leaving room for a border. That pane grows by one cell and the pane
on the other side is neither moved nor resized.

• A separator is only covered when every pane along that side of it asks, so a
  pane sharing a separator with a neighbour that does not ask is left alone and
  mixed layouts keep the current behaviour.
• When the panes on both sides ask, the one before it wins, so all removes
  every separator in a window rather than none of them.
• A pane with a pane-border-status line never claims a separator, because the
  status line is drawn in it.

Approach

The layout cells are deliberately left alone and only the pane inside a cell is
made larger, in the same place layout_fix_panes() already shrinks a pane to
make room for a pane border status line.

This keeps the change small, but more importantly it keeps #{window_layout}
identical whether or not the option is set, so layouts stay portable between
builds with and without it in both directions. Changing the cell sizes would
not, since layout_check() assumes one cell per boundary.

Panes drawn over a separator also stop marking a border along that side,
otherwise the cells at each end of it are given a line pointing at a separator
that is no longer drawn and appear as a T.

Trade-offs

• A covered separator cannot be dragged with the mouse, because pane content
  now covers it. The panes either side can still be resized with resize-pane,
  as the separator still exists in the layout.
• pane-border-status and this option do not combine on the same separator, by
  design.

Tests

regress/pane-border-collapse.sh covers geometry on both sides of a
separator, all four directions, the side facing away from a separator being
ignored, both sides claiming, all, pane-border-status blocking a claim, and
a separator shared by two panes where only one of them claims it. It also
asserts #{window_layout} is unchanged.

Also checked by hand: rendering with pane-border-lines simple (no stray T
where a collapsed separator crosses a vertical one), resize-pane across a
collapsed separator, window resize and a shrink to 20x5, layout dump and
re-apply, zoom and unzoom, and floating panes, which never claim a separator.

The rest of regress passes apart from input-keys.sh and
screen-redraw-menus.sh, which behave the same way on master here.

Related

#5433 is related but solves a different problem in the opposite direction:
pane-border-type separate draws a full border around each pane and
separate-active keeps a blank gutter, so both use more cells between
neighbours rather than fewer. #4236 and #2720 asked for borders to be removed
and were closed. I could not find existing work that reclaims tiled border
geometry, but I may have missed it.