[gdb/testsuite] Update xfail in gdb.threads/attach-many-short-lived-threads.exp

With test-case gdb.threads/attach-many-short-lived-threads.exp, I run into:
...
(gdb) attach 7773^M
Attaching to program: attach-many-short-lived-threads, process 7773^M
Cannot attach to lwp 7776: Operation not permitted (1)^M
(gdb) PASS: $exp: iter 1: attach
info threads^M
No threads.^M
(gdb) PASS: $exp: iter 1: no new threads
set breakpoint always-inserted on^M
(gdb) PASS: $exp: iter 1: set breakpoint always-inserted on
break break_fn^M
Breakpoint 1 at 0x400b4d: file attach-many-short-lived-threads.c, line 57.^M
(gdb) PASS: $exp: iter 1: break break_fn
continue^M
The program is not being run.^M
(gdb) FAIL: $exp: iter 1: break at break_fn: 1 \
  (the program is no longer running)
...

There's some code in the test-case dealing with a similar warning:
...
  -re "warning: Cannot attach to lwp $decimal: Operation not permitted" {
...

But since commit c6f7f9c80c ("Bail out of "attach" if a thread cannot be
traced"), the warning has been changed into an error.

Fix the FAIL by updating the test-case to expect an error instead of a
warning.

Tested on x86_64-linux.

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

gdb/testsuite/gdb.threads/attach-many-short-lived-threads.exp

@@ -74,7 +74,7 @@ proc test {} {
 		    # Seen when "set debug libthread_db" is on.
 		    exp_continue
 		}
-		-re "warning: Cannot attach to lwp $decimal: Operation not permitted" {
+		-re "Cannot attach to lwp $decimal: Operation not permitted" {
 		    # On Linux, PTRACE_ATTACH sometimes fails with
 		    # EPERM, even though /proc/PID/status indicates
 		    # the thread is running.
@@ -96,6 +96,10 @@ proc test {} {
 		}
 	    }
 
+	    if { $eperm } {
+		continue
+	    }
+
 	    # Sleep a bit and try updating the thread list.  We should
 	    # know about all threads already at this point.  If we see
 	    # "New Thread" or similar being output, then "attach" is