[gdb/testsuite] Don't leave gdb instance running after function_range

[gdb/testsuite] Don't leave gdb instance running after function_range

A typical dwarf assembly test-case start like this:
...
standard_testfile .c -debug.S

set asm_file [standard_output_file $srcfile2]
Dwarf::assemble $asm_file {
  ...
}

if { [prepare_for_testing "failed to prepare" ${testfile} \
	  [list $srcfile $asm_file] {nodebug}] } {
    return -1
}
...

When accidentally using build_for_executable instead of
prepare_for_testing (or intentionally using it but forgetting to add
clean_restart $binfile or some such) the mistake may not be caught, because
another gdb instance is still running, and we may silently end up testing
compiler-generated DWARF.

This can be caused by something relatively obvious, like an earlier
prepare_for_testing or clean_restart, but also by something more obscure like
function_range, which may even be triggered by dwarf assembly like this:
...
  {MACRO_AT_func {main}}
...

Fix this by calling gdb_exit at the end of function_range.

Also fix the fallout of that in test-case gdb.dwarf2/dw2-bad-elf.exp, where a
get_sizeof call used the gdb instance left lingering by function_range.

[ A better and more complete fix would add a new proc get_exec_info, that would
be called at the start of the dwarf assembly body:
...
Dwarf::assemble $asm_file {
  get_exec_info {main foo} {int void*}
...
that would:
- do a prepare_for_testing with $srcfile (roughtly equivalent to what
  MACRO_AT_func does,
- call function_range for all functions main and foo, without starting a
  new gdb instance
- set corresponding variables at the call-site: main_start, main_len,
  main_end, foo_start, foo_len, foo_end.
- get size for types int and void*
- set corresponding variables at the call-site: int_size, void_ptr_size.
- do a gdb_exit. ]

Tested on x86_64-linux.