[gdb/testsuite] Stop on main in gdb.gdb/{python-helper,selftest}.exp

[gdb/testsuite] Stop on main in gdb.gdb/{python-helper,selftest}.exp

With a gdb build with gcc 15.1.1 and "-O2 -flto=auto -g", I run into:
...
UNTESTED: gdb.gdb/selftest.exp: \
  Cannot set breakpoint at captured_main, skipping testcase.
UNTESTED: gdb.gdb/python-helper.exp: \
  Cannot set breakpoint at captured_main, skipping testcase.
...

I don't know why we're trying to stop in captured_main.

Stopping in main also works, and main is more likely to be present in an lto
build.

Fix this by using main instead.

This requires us to update the expected file name from main.c to gdb.c in
selftest_setup.

After doing so, we get:
...
XFAIL: gdb.gdb/selftest.exp: \
  run until breakpoint at main (line numbers scrambled?)
XFAIL: gdb.gdb/python-helper.exp: \
run until breakpoint at main (line numbers scrambled?)
...
because main is reported to be in run-on-main-thread.c instead of gdb.c:
.
Breakpoint 1, main (...) at gdb/run-on-main-thread.c:120^M
...

This is due to picking the last line entry for pc == 0x455e40 that has
is_stmt == true:
...
File name                      Line number    Starting address    View    Stmt

gdb/gdb.c:
gdb.c                                   25            0x455e40               x
gdb.c                                   30            0x455e40       1       x

gdb/run-on-main-thread.c:
run-on-main-thread.c                   116            0x455e40       2       x
run-on-main-thread.c                   120            0x455e40       3       x

gdb/gdb.c:
gdb.c                                   25            0x455e40       4

/usr/include/c++/15/bits/std_thread.h:
std_thread.h                           366            0x455e4b
...

While we're at it, update the corresponding gdb_test_multiple in
selftest_setup using multi_line and -wrap.

Tested on x86_64-linux.