gdb/tui: function name in status bar for tailcall functions

gdb/tui: function name in status bar for tailcall functions

I noticed that the function name displayed in the TUI status bar was
wrong for tail call frames.  I spotted this after commit:

  commit f163103c364f72be00f7580ac7500e10c18230a3
  Date:   Mon Jan 12 10:44:35 2026 +0000

      gdb: fix 'info frame' for tail calls with no debug information

And playing with the test binary from that commit in the TUI.

Unlike the problem fixed by this earlier commit, the TUI status bar
function name is wrong for tail call functions both with and without
DWARF.

The problem is in the function tui_get_function_from_frame (in
tui/tui-status.c), which the TUI uses to get the function name that
will be displayed.  This function calls print_address_symbolic passing
in the result of a call to get_frame_pc to get the actual function
name.

The problem is that for a tail calls, get_frame_pc will return a pc
outside the current function.  Fix this by switching to use the
function get_frame_address_in_block instead.

I wanted the tests for this fix to live in gdb.tui/ as the code being
fixed is very TUI specific.  As a result this does mean that the
tailcall-msym.exp test is copied from gdb.base/ (see the earlier
commit), but I don't see this as a huge problem.

There's an additional test that creates a tail call function using the
DWARF assembler, this tests the with DWARF case.

One maybe surprising change in this commit is the one to lib/gdb.exp.
This was needed because of the use of 'runto callee' in the new
tests.  As we're running in TUI mode, styling will be enabled in the
output.  Now most TUI tests compile "normal" .c files into an
executable with file and line debug information.  As a result, when we
hit a breakpoint we see GDB output like:

  Breakpoint 1, function () at file.c:25

The pattern that matches this within 'proc runto' (lib/gdb.exp)
uses '.*' to match both the function name and the filename.  This
means that the styling escape sequences are also matched.

However, when building the tests added in this commit, which lack file
and line debug information, we get a breakpoint hit line like this:

  Breakpoint 1, 0x000000000040110a in callee ()

The pattern in 'proc runto' that matches this uses '[0-9xa-f]*' to
match the hex address string.  As a consequence, if the address is
styled, then this pattern no longer matches.

To work around this I've added an optional pattern which should match
any ansi styling escape sequence before and after the address.  This
should not cause any problems for unstyled testing, but now allows
this pattern to match if styling is enabled.

Approved-By: Tom Tromey <tom@tromey.com>