tests/valgrind: fix handling of forks

[gperciva]

No description provided.

[gperciva]

We tried to support valgrind checking of fork() in:

2023-09-20 tests/valgrind: improve handling for fork() and exec()
38e07b4

However, that method assumed that the first pid would be the parent, while the second (and subsequent ones) would be the children. That has two flaws:

1. if the pid rolls over, the order would be broken. For example, if
   the parent pid was 99999 on FreeBSD (the maximum value), then the
   child would be something much lower (probably in the hundreds).

   (I knew about that problem, considered it sufficiently unlikely.)

2. since $_valgrind_check_logfiles are defined by ls "blah"*, they are
   listed in lexicographical order, not numerical order. For example,
   given two logfiles foo-9999.log and foo-10000.log, foo-10000.log
   would come first.

   (I did not anticipate this problem, but even if it had occurred to
   me, I probably would have deemed it sufficiently unlikely. However,
   by an unlikely fluke, this seems to occur roughly 50% of the time with
   github actions: when checking 24-fork-func with the gcc binaries, the parent
   lands on pid 9999 exactly and the child is 10000.)

The fix is not to rely on the order: instead, generate a list of all pids involved. If a valgrind logfile lists a parent pid which is in that list, it's a child; otherwise, it's the parent.