Fix "attach" command vs user input race

Fix "attach" command vs user input race

On async targets, a synchronous attach is done like this:

   #1 - target_attach is called (PTRACE_ATTACH is issued)
   #2 - a continuation is installed
   #3 - we go back to the event loop
   #4 - target reports stop (SIGSTOP), event loop wakes up, and
        attach continuation is called
   #5 - among other things, the continuation calls
        target_terminal_inferior, which removes stdin from the event
        loop

Note that in #3, GDB is still processing user input.  If the user is
fast enough, e.g., with something like:

  echo -e "attach PID\nset xxx=1" | gdb

... then the "set" command is processed before the attach completes.

We get worse behavior even, if input is a tty and therefore
readline/editing is enabled, with e.g.,:

 (gdb) attach PID\nset xxx=1

we then crash readline/gdb, with:

 Attaching to program: attach-wait-input, process 14537
 readline: readline_callback_read_char() called with no handler!
 Aborted
 $

Fix this by calling target_terminal_inferior before #3 above.

The test covers both scenarios by running with editing/readline forced
to both on and off.

gdb/
2014-07-09  Pedro Alves  <palves@redhat.com>

	* infcmd.c (attach_command_post_wait): Don't call
	target_terminal_inferior here.
	(attach_command): Call it here instead.

gdb/testsuite/
2014-07-09  Pedro Alves  <palves@redhat.com>

	* gdb.base/attach-wait-input.exp: New file.
	* gdb.base/attach-wait-input.c: New file.