tests/fdgrowtable: open more files in the threaded case

tests/fdgrowtable: open more files in the threaded case

This should fix the test failing on some machines/conditions/runs.  This
won't fix failures in standalone run, but should fix kyua(1) runs.
Currently with standalone run it will usually fail because the 40-sized
allocation is skipped (see details below).

This matches what forking test does: open 128 files in the parent and 128
in the child.  There should actually be no difference where and when the
files are open, but let's mimic the forking test, and open more files in
the spawned thread.  Also opening from two different contexts adds a bit
more entropy to the test.

What the test does it checks that fdgrowtable() has been called at least
three tmes for the test process, and the old tables are still on the free
list as long as other execution contexts exist.  Under kyua(1) control the
first call grows the table from 20 to 40, but the original table of 20 is
an embedded one, thus is not put on the free list.  Passing 40 open files
the table grows to 128 and first old table lands on the free list. Passing
128 open file the table grows to 256 and a second old table lands on the
free list.  After that the test would pass.  The threaded test was one
open file off before this fix sometimes.