Fix nested gdb_caching_proc with args

Fix nested gdb_caching_proc with args

Commit d09eba07 ("Make get_compiler_info use gdb_caching_proc")
regressed some tests when you run them in isolation (as this depends
on the order the gdb_caching_proc procs' results are cached).

E.g.:

 Running /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp ...
 ERROR: tcl error sourcing /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp.
 ERROR: tcl error code TCL WRONGARGS
 ERROR: wrong # args: should be "gdb_real__get_compiler_info_1 language"
     while executing
 "gdb_real__get_compiler_info_1"
     ("uplevel" body line 1)
     invoked from within
 "uplevel 2 $real_name"
     (procedure "gdb_do_cache_wrap" line 3)
     invoked from within
 "gdb_do_cache_wrap $real_name {*}$args"
     (procedure "gdb_do_cache" line 98)
     invoked from within

gdb.base/attach.exp triggers it too, for example.

This is actually a latent problem in gdb_do_cache_wrap, introduced in:

 commit 71f1ab80f1aabd70bce526635f84c7b849e8a0f4
 CommitDate: Mon Mar 6 16:49:19 2023 +0100

    [gdb/testsuite] Allow args in gdb_caching_proc

This change:

   # Call proc real_name and return the result, while ignoring calls to pass.
  -proc gdb_do_cache_wrap {real_name} {
  +proc gdb_do_cache_wrap {real_name args} {
       if { [info procs save_pass] != "" } {
	  return [uplevel 2 $real_name]   <<<<<<<<<<<<<<<<<<<<<<< HERE
       }
  @@ -31,7 +31,7 @@ proc gdb_do_cache_wrap {real_name} {
       rename pass save_pass
       rename ignore_pass pass

  -    set code [catch {uplevel 2 $real_name} result]
  +    set code [catch {uplevel 2 [list $real_name {*}$args]} result]

Missed updating the line marked with HERE above, to pass down $args.
So the case of a caching proc calling another caching proc with args
isn't handled correctly.

We could fix this by fixing the HERE line like so:

 -	  return [uplevel 2 $real_name]
 +	  return [uplevel 2 [list $real_name {*}$args]]

However, we have with_override nowadays that we can use here which
eliminates the duplicated logic, which was what was missed originally.

A new test that exposes the problem is added to
gdb.testsuite/gdb-caching-proc.exp.

This also adds a new test to gdb.testsuite/with-override.exp that I
think was missing, making sure that the inner foo override restores
the outer foo override.

Tested-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I8b2a7366bf910902fe5f547bde58c3b475bf5133