gdb/tui: support placing the cmd window into a horizontal layout

gdb/tui: support placing the cmd window into a horizontal layout

This commit allows the user to place the cmd window within horizontal
tui layouts.  Consider this set of steps, carried out in an 80 columns
by 24 lines terminal, using current master gdb:

  (gdb) tui new-layout hsrc { -horizontal src 1 cmd 1 } 1 status 1
  (gdb) tui layout hsrc

What you end up with is a full width cmd window with the status bar
beneath.  Where's the src window gone?  We then try:

  (gdb) info win
  Name       Lines Columns Focus
  src           23       3 (has focus)
  cmd           23      80
  status         1      80
  (gdb)

Something weird has gone on, gdb has overlapped the cmd window with
the src window.  If we trigger the src window to redraw is content,
for example, 'list main', then we see corruption in the cmd window as
the src window overwrites it.

So, what's going on?

The problem is some code in tui_layout_split::apply, in tui-layout.c.
Within 'Step 1', there is a loop that calculates the min/max window
sizes for all windows within a tui_layout_split.  However, there's a
special case for the cmd window.

This special case is trying to have the cmd window retain its current
size when a layout is re-applied, or a new layout is applied.  This
makes sense, consider moving from the 'src' layout to the 'asm'
layout, this looks something like this (status window removed):

    .-------.         .-------.
    |  src  |         |  asm  |
    |-------|  ====>  |-------|
    |  cmd  |         |  cmd  |
    '-------'         '-------'

If the user has gone to the effort of adjusting the cmd window size,
then, the thinking goes, we shouldn't reset the cmd window size when
switching layouts like this.

The problem though, is that when we do a switch more like this:

    .-----------.         .-----------.
    |    src    |         |     |     |
    |-----------|  ====>  | asm | cmd |
    |    cmd    |         |     |     |
    '-----------'         '-----------'

Now retaining the cmd window width makes no sense; the new layout has
a completely different placement for the cmd window, instead of sizing
by height, we're now sizing by width.  The existing code doesn't
understand this though, and tried to retain the full width for the cmd
window.

To solve this problem, I propose we introduce the idea of a layout
"fingerprint".  The fingerprint tries to capture, in an abstract way,
where the cmd window lives within the layout.

Only when two layouts have the same fingerprint will we attempt to
retain the cmd window size.

The fingerprint for a layout is represented as a string, the string is
a series of 'V' or 'H' characters, ending with a single 'C'
character.  The series of 'V' and 'H' characters represent the
vertical or horizontal layouts that must be passed through to find the
cmd window.

Here are a few examples:

  # This layout is equivalent to the builtin 'src' layout.
  # Fingerprint: VC
  tui new-layout example1 src 2 status 0 cmd 1

  # This layout is equivalent to the builtin 'split' layout.
  # Fingerprint: VC
  tui new-layout example2 src 1 asm 1 status 0 cmd 1

  # This is the same layout that was given at the top.
  # Fingerprint: VHC
  tui new-layout hsrc { -horizontal src 1 cmd 1 } 1 status 1

And so, when switching between example1 and example2, gdb knows that
the cmd window is, basically, in the same sort of position within the
layout, and will retain the cmd window size.

In contrast, when switching to the hsrc layout, gdb understands that
the position of the cmd window is different, and does not try to
retain the cmd window size.