Fix "attach" failure handling with GDBserver

Fix "attach" failure handling with GDBserver

This fixes the same issue as the previous patch, but for "attach"
instead of "run".

If attaching to a process with "attach" (vAttach packet) fails,
GDBserver throws an error that escapes all the way to the top level.
When an error escapes all the way like that, GDBserver interprets it
as a disconnection, and either goes back to waiting for a new GDB
connection, or exits, if --once was specified.

Here's an example:

On the GDB side:

 ...
 (gdb) tar extended-remote :9999
 ...
 Remote debugging using :9999
 (gdb) attach 1
 Attaching to process 1
 Attaching to process 1 failed
 (gdb)

On the GDBserver side:

 $ gdbserver --once --multi :9999
 Listening on port 9999
 Remote debugging from host 127.0.0.1, port 37464
 gdbserver: Cannot attach to process 1: Operation not permitted (1)
 $   # gdbserver exited

This is wrong, as we've connected with extended-remote/--multi.
GDBserver should just report an error to vAttach, and continue
connected to GDB, waiting for other commands.

This commit fixes GDBserver by catching the error locally in
handle_v_attach.

Note we now let pid == 0 pass down to attach_inferior.  That is so we
get a useful textual error message to report to GDB.

This fixes a couple KFAILs in gdb.base/attach.exp.  Still, I thought
it would be useful to add a new testcase specifically for this
scenario, in case gdb.base/attach.exp is ever split and stops trying
to attach again after a failed attach, with the same GDB session.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19558
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554

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