gdbsupport: re-work parallel_for_each test, again

gdbsupport: re-work parallel_for_each test, again

I started working on this patch because I noticed that this
parallel_for_each test:

    /* Check that if there are fewer tasks than threads, then we won't
       end up with a null result.  */

is not really checking anything.  And then, this patch ended with
several changes, leading to general refactor of the whole file.

This test verifies, using std::all_of, that no entry in the intresults
vector is nullptr.  However, nothing ever adds anything to intresults.
Since the vector is always empty, std::all_of is always true.  This
state probably dates back to afdd1366358c ("Back out some
parallel_for_each features"), which removed the ability for
parallel_for_each to return a vector of results.  That commit removed
some tests, but left this one in, I'm guessing as an oversight.

One good idea in this test is to check that the worker never receives
empty ranges.  I think we should always test for that.  I think it's
also a good idea to test with exactly one item, that's a good edge case.

To achieve this without adding some more code duplication, factor out
the core functionality of the test in yet another test_one function (I'm
running out of ideas for names).  In there, check that the range
received by the worker is not empty.  Doing this pointed out that the
worker is actually called with empty ranges in some cases, necessitating
some minor changes in parallel-for.h.

Then, instead of only checking that the sum of the ranges received by
worker functions is the right count, save the elements received as part
of those ranges (in a vector), and check that this vector contains each
expected element exactly once.  This should make the test a bit more
robust (otherwise we could have the right number of calls, but on the
wrong items).

Then, a subsequent patch in this series changes the interface or
parallel_for_each to use iterator_range.  The only hiccup is that it
doesn't really work if the "RandomIt" type of the parallel_for_each is
"int".  iterator_range<int>::size wouldn't work, as std::distance
doesn't work on two ints.  Fix this in the test right away by building
an std::vector<int> to use as input.

Finally, run the test with the default thread pool thread count in
addition to counts 0, 1 an 3, currently tested.  I'm thinking that it
doesn't hurt to test parallel_for_each in the configuration that it's
actually used with.

Change-Id: I5adf3d61e6ffe3bc249996660f0a34b281490d54
Approved-By: Tom Tromey <tom@tromey.com>