gdbserver/lynx178: spurious SIG61 signal when resuming inferior.

On ppc-lynx178, resuming the execution of a program after hitting
a breakpoint sometimes triggers a spurious SIG61 event:

    (gdb) cont
    Continuing.

    Program received signal SIG61, Real-time event 61.
    [Switching to Thread 39]
    0x10002324 in a_test.task1 (<_task>=0x3ffff774) at a_test.adb:30
    30          select  -- Task 1

From this point on, continuing again lets the signal kill the program.
Using "signal 0" or configuring GDB to discard the signal does not
help either, as the program immediately reports the same signal again.

What happens is the following:

  - GDB sends a single-step order to gdbserver: $vCont;s:31
    This tells GDBserver to do a step using thread 0x31=49.
    GDBserver does the step, and thread 49 receives the SIGTRAP
    indicating that the step has finished.

  - GDB then sends a "continue", but this time does not specify
    which thread to continue: $vCont;c
    GDBserver uses an arbitrary thread's ptid to resume the program's
    execution (the current_inferior's ptid was chosen for that).
    See lynx-low.c:lynx_resume:

        if (ptid_equal (ptid, minus_one_ptid))
          ptid = thread_to_gdb_id (current_inferior);

So far on all LynxOS platforms, this has been good enough. But
not so on LynxOS 178. If the ptid used to resume the execution
is not the same as the thread that did the step, we get the weird
signal.

This patch fixes the problem by saving the ptid of the thread
that last caused an event, received during a call to waitpid.
The ptid is saved in per-process private data.

gdb/gdbserver/ChangeLog:

        * lynx-low.c (struct process_info_private): New type.
        (lynx_add_process): New function.
        (lynx_create_inferior, lynx_attach): Replace calls to
        add_process by calls to lynx_add_process.
        (lynx_resume): If PTID is null, then try using
        current_process()->private->last_wait_event_ptid.
        Add comments.
        (lynx_clear_inferiors): Delete.  The contents of that function
        has been inlined in lynx_mourn;
        (lynx_wait_1): Save the ptid in the process's private data.
        (lynx_mourn): Free the process' private data.  Replace call
        to lynx_clear_inferiors by call to clear_inferiors.
[gdbserver/lynx178]: Fix null_ptid -vs- minus_one_ptid confusion in comment

gdb/gdbserver/ChangeLog:

        * lynx-low.c (lynx_resume): Fix null_ptid/minus_one_ptid
        confusion in comment.