Make follow_fork not rely on get_last_target_status

Make follow_fork not rely on get_last_target_status

Currently, if

  - you're in all-stop mode,
  - the inferior last stopped because of a fork catchpoint,

when you next resume the program, gdb checks whether it had last
stopped for a fork/vfork, and if so,

 a) if the current thread is the one that forked, gdb follows the
   parent/child, depending on "set follow-fork" mode.

 b) if the current thread is some other thread (because you switched
   threads meanwhile), gdb switches back to that thread, gdb follows
   the parent/child, and stops the resumption command.

There's a problem in b), however -- if you have "set schedule-multiple
off", which is the default, or "set scheduler-locking on", gdb will
still switch back to the forking thread, even if you didn't want to
resume it.  For example, with:

  (gdb) catch fork
  (gdb) c
  * thread 1 stops for fork
  (gdb) thread 2
  (gdb) set scheduler-locking on
  (gdb) c

gdb switches back to thread 1, and follows the fork.

Or with:

  (gdb) add-inferior -exec prog
  (gdb) inferior 2
  (gdb) start
  (gdb) inferior 1
  (gdb) catch fork
  (gdb) c
  * thread 1.1 stops for fork
  (gdb) inferior 2
  (gdb) set schedule-multiple off # this is the default
  (gdb) c

gdb switches back to thread 1.1, and follows the fork.

Another issue is that, because follow_fork relies on
get_last_target_status to find the thread that has a pending fork, it
is possible to confuse it.  For example, "run" or "start" call
init_wait_for_inferior, which clears the last target status, so this:

  (gdb) catch fork
  (gdb) c
  * thread 1 stops for fork
  (gdb) add-inferior -exec prog
  (gdb) inferior 2
  (gdb) start
  (gdb) set follow-fork child
  (gdb) inferior 1
  (gdb) n

... does not follow to the fork child of inferior 1, because the
get_last_target_status call in follow_fork doesn't return a
TARGET_WAITKIND_FORKED.  Thanks to Simon for this example.

All of the above are fixed by this patch.  It changes follow_fork to
not look at get_last_target_status, but to instead iterate over the
set of threads that the user is resuming, and find the one that has a
pending_follow kind of fork/vfork.

gdb.base/foll-fork.exp is augmented to exercise the last "start"
scenario described above.  The other cases will be exercised in the
testcase added by the following patch.

Change-Id: Ifcca77e7b2456277387f40660ef06cec2b93b97e