Improve "info program"

Improve "info program"

With gdb.base/catch-follow-exec.exp, we currently see:

~~~~~~~~~~~~~~~
 (gdb)
 continue
 Continuing.
 process 693251 is executing new program: /usr/bin/ls
 [New inferior 2]
 [New process 693251]
 [Switching to process 693251]

 Thread 2.1 "ls" hit Catchpoint 2 (exec'd /usr/bin/ls), 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2
 (gdb)
 info prog
 No selected thread.
~~~~~~~~~~~~~~~

Note the "No selected thread" output.  That is totally bogus, because
there _is_ a selected thread.  What GDB really means, is that it can't
find the thread that had the latest (user-visible) stop.  And that
happens because "info program" gets that info from
get_last_target_status, and the last target status has been cleared.

However, GDB also checks if there is a selected thread, here:

  if (ptid == null_ptid || ptid == minus_one_ptid)
    error (_("No selected thread."));

.. the null_ptid part.  That is also bogus, because what matters is
the thread that last reported a stop, not the current thread:

 - in all-stop mode, "info program" displays info about the last stop.
   That may have happened on a thread different from the selected
   thread.

 - in non-stop mode, because all threads are controlled individually,
   "info program" shows info about the last stop of the selected
   thread.

The current code already behaves this way, though in a poor way.  This
patch reimplements it, such that the all-stop version now finds the
thread that last reported an event via the 'previous_thread' strong
reference.  Being a strong reference means that if that thread has
exited since the event was reported, 'previous_thread' will still
point to it, so we can say that the thread exited meanwhile.

The patch also extends "info program" output a little, to let the user
know which thread we are printing info for.  For example, for the
gdb.base/catch-follow-exec.exp case we shown above, we now get:

 (gdb) info prog
 Last stopped for thread 2.1 (process 710867).
	 Using the running image of child process 710867.
 Program stopped at 0x7ffff7fd0100.
 It stopped at breakpoint 2.
 Type "info stack" or "info registers" for more information.
 (gdb)

while in non-stop mode, we get:

 (gdb) info prog
 Selected thread 2.1 (process 710867).
	 Using the running image of child process 710867.
 Program stopped at 0x7ffff7fd0100.
 It stopped at breakpoint 2.
 Type "info stack" or "info registers" for more information.
 (gdb)

In both cases, the first line of output is new.

The existing code considered these running/exited cases as an error,
but I think that that's incorrect, since this is IMO just plain
execution info as well.  So the patch makes those cases regular
prints, not errors.

If the thread is running, we get, in non-stop mode:

 (gdb) info prog
 Selected thread 2.1 (process 710867).
 Selected thread is running.

... and in all-stop:

 (gdb) info prog
 Last stopped for thread 2.1 (process 710867).
 Thread is now running.

If the thread has exited, we get, in non-stop mode:

 (gdb) info prog
 Selected thread 2.1 (process 710867).
 Selected thread has exited.

... and in all-stop:

 (gdb) info prog
 Last stopped for thread 2.1 (process 710867).
 Thread has since exited.

The gdb.base/info-program.exp testcase was much extended to test
all-stop/non-stop and single-threaded/multi-threaded.

Change-Id: I51d9d445f772d872af3eead3449ad4aa445781b1