sim: rewrite SIM_AC_OPTION_HARDWARE a bit to simplify things

There's no need to put the majority of the logic into the 3rd arg of the
AC_ARG_ENABLE.  Coupled with the lack of indentation, it makes it hard to
follow, error prone to update, and duplicates code (with the 4th arg).

So pull the logic out of the 3rd arg and outside of the AC_ARG_ENABLE
macro.  This allows us to gut the 4th arg entirely, merge with the code
that followed the macro, and fix bugs related to the new dv-sockser in
the process.

Hopefully building the various sims with the default sim-hardware
settings, as well as with explicit --{dis,en}able-sim-hardware flags,
should all just work now.
"set record instruction-history-size"/"set record function-call-history-size" range validation.

While the commands are uinteger, the target interfaces are limited to
INT_MAX.  Don't let the user request more than we can handle.

gdb/
2013-03-26  Pedro Alves  <palves@redhat.com>

	* record.c (record_insn_history_size_setshow_var)
	(record_call_history_size_setshow_var): New globals.
	(command_size_to_target_size): New function.
	(cmd_record_insn_history, cmd_record_call_history): Use
	command_size_to_target_size instead of cast.
	(validate_history_size, set_record_insn_history_size)
	(set_record_call_history_size): New functions.
	(_initialize_record): Install set_record_insn_history_size and
	set_record_call_history_size as "set" hooks of "set record
	instruction-history-size" and "set record
	function-call-history-size".
Get rid of "No such file or directory" in the testsuite's btrace support detection.

When I tried running the btrace tests, I noticed something odd in the gdb.log file:

 (gdb) run
 Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.x
 Breakpoint 1, main () at /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.c:1
 1       /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.c: No such file or directory.
                                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^
 (gdb) record btrace
 Target does not support branch tracing.
 (gdb) testcase ../../../src/gdb/testsuite/gdb.btrace/enable.exp completed in 0 seconds

I knew that the btrace tests on my machine weren't supposed to work,
but still, that error made me wonder if the test had something broken,
and waste a few minutes looking up where that is coming from.

The issue is that the btrace detection deletes the source file right
after compiling it, and before GDB has a chance to open it.  It's
really harmless, but I'd rather spare others from going through the
same exercise.

We now get the regular:

 (gdb) run
 Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace24210.x
 ...
 Breakpoint 1, main () at /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace24210.c:1
 1       int main(void) { return 0; }
 ...

gdb/testsuite/
2013-03-26  Pedro Alves  <palves@redhat.com>

	* lib/gdb.exp (skip_btrace_tests): Delay deleting the source file
	until after GDB has run.
Make "set/show debug coff_pe_read" a zuinteger instead of uinteger.

Being a uinteger means you can't disable debug output after enabling it...

  (gdb) show debug coff_pe_read
  Coff PE read debugging is 0.
  (gdb) set debug coff_pe_read 0
  (gdb) show debug coff_pe_read
  Coff PE read debugging is unlimited.
  (gdb)

gdb/
2013-03-26  Pedro Alves  <palves@redhat.com>

	* coff-pe-read.c (_initialize_coff_pe_read): Make the command
	zuinteger instead of uinteger.
Make "set/show cris-version" a zuinteger instead of uinteger.

Being a uinteger means you revert back to having GDB decide the
version.  It makes no sense to have an "unlimited" version.

  (gdb) show cris-version
  The current CRIS version is 0.
  (gdb) set cris-version 0
  (gdb) show cris-version
  The current CRIS version is unlimited.
  (gdb)

gdb/
2013-03-26  Pedro Alves  <palves@redhat.com>

	* cris-tdep.c (_initialize_cris_tdep): Make the "set cris-version"
	command zuinteger instead of uinteger.