Provding a default compiler in default_target_compile

One of the minor bugs on my local TODO list for some time now has been 
cleaning up whatever it is that produces lots of messages ending in 
"xgcc" at verbose 2+.  I had quickly found that those messages are from 
the find_gcc procedure and that it is being called at {set_board_info 
compiler "[find_gcc]"} in baseboards/unix.exp.  At the time, I did not 
understand enough to propose a solution and just left it in my TODO list.

I now have a solution:  establish a default compiler in 
default_target_compile, by using [find_gcc] if the compiler_type is 
still the default "c" just before complaining about "No compiler to 
compile with" and make the "compiler" key in board_info optional.  I am 
asking about this before making a patch, since the patch will involve 
removing {set_board_info compiler "[find_gcc]"} from all of the 
baseboard files that use it, except for multi-sim, which is the only 
file that seems to actually rely on it -- in the others, it is just 
boilerplate.  (And I currently believe that if you are running with a 
multi-sim target, you probably *do* want to compile test cases, so you 
really do need the compiler.)  A quick grep suggests that nothing else 
relies on the board_info compiler option:  
lib/libgloss.exp:get_multilibs will use it as an override, but falls 
back to [find_gcc] if it is not defined.

Setting the board_info compiler value to "[find_gcc]" would still work, 
of course, (and leaving it in multi-sim will help to ensure this) so 
existing out-of-tree board files would not break as a result of this 
change.  In effect, I propose a default value for [board_info $whatever 
compiler] that is only evaluated if the testsuite actually wants to use 
a compiler.  This change would both reduce "noise" at higher verbose 
levels and reduce the boilerplate needed for a baseboard file.

Any comments on the idea before I write a patch?  If we use [find_gcc] 
in default_target_compile, should we memoize the result using 
set_board_info?  Or is find_gcc fast enough that evaluating it 
repeatedly would not be a problem?

-- Jacob