Make get_compiler_info use gdb_caching_proc

Make get_compiler_info use gdb_caching_proc

While running tests on Windows with:

 $ make check-parallel RUNTESTFLAGS="-v"

I noticed that get_compiler_info was invoking the compiler over and
over for each testcase, even though the result is supposed to be
cached.

This isn't normally very visible in gdb.log, because we suppress it
there:

    # Run $ifile through the right preprocessor.
    # Toggle gdb.log to keep the compiler output out of the log.
    set saved_log [log_file -info]
    log_file
    ...

I'm not sure it's a good idea to do that suppression, BTW.  I was very
confused when I couldn't find the compiler invocation in gdb.log, and
it took me a while to notice that code.

The reason get_compiler_info in parallel mode isn't hitting the cache
is that in that mode each testcase runs under its own expect/dejagnu
process, and the way get_compiler_info caches results currently
doesn't handle that -- the result is simply cached in a global
variable, which is private to each expect.

So improve this by switching get_compiler_info's caching mechanism to
gdb_caching_proc instead, so that results are cached across parallel
invocations of dejagnu.

On an x86-64 GNU/Linux run with "make check-parallel -j32", before the
patch I get 2223 calls to get_compiler_info that result in a compiler
invocation.  After the patch, I get 7.

On GNU/Linux, those compiler invocations don't cost much, but on
Windows, they add up.  On my machine each invocation takes around
500ms to 700ms.  Here is one representative run:

  $ time x86_64-w64-mingw32-gcc  \
     /c/msys2/home/alves/gdb/build-testsuite/temp/14826/compiler.c \
     -fdiagnostics-color=never -E
  ...
  real    0m0.639s
  user    0m0.061s
  sys     0m0.141s

This reference to a 'compiler_info' global:

 # N.B. compiler_info is intended to be local to this file.
 # Call test_compiler_info with no arguments to fetch its value.
 # Yes, this is counterintuitive when there's get_compiler_info,
 # but that's the current API.
 if [info exists compiler_info] {
     unset compiler_info
 }

is outdated, even before this patch, as "compiler_info" is a local
variable in get_compiler_info.  Remove all that code.

Since test_compiler_info now calls get_compiler_info directly, the
"Requires get_compiler_info" comments in skip_inline_frame_tests and
skip_inline_var_tests are no longer accurate.  Remove them.

test_compiler_info's intro comment is also outdated; improve it.

Changing the return value of get_compiler_info to be the
'compiler_info' string directly instead of 0/-1 was simpler.  It would
be possible to support the current 0/-1 interface by making
get_compiler_info_1 still return the 'compiler_info' string, and then
having the get_compiler_info wrapper convert to 0/-1, and I considered
doing that.  But the only caller of get_compiler_info outside gdb.exp
is gdb.python/py-event-load.exp, and it seems that one simply crossed
wires with:

 commit 9704b8b4bc58f4f464961cca97d362fd33740ce8
 gdb/testsuite: remove unneeded calls to get_compiler_info

as the test as added at roughly the same time as that commit.

So simply remove that call in gdb.python/py-event-load.exp, otherwise
we get something like:

 ERROR: -------------------------------------------
 ERROR: in testcase src/gdb/testsuite/gdb.python/py-event-load.exp
 ERROR:  expected boolean value but got "gcc-13-3-0"
 ERROR:  tcl error code TCL VALUE NUMBER
 ERROR:  tcl error info:
 expected boolean value but got "gcc-13-3-0"

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