[C++] Create new thread pool benchmark demonstrating the "scheduling" bottleneck

The benchmark ThreadPoolSpawn (in thread_pool_benchmark.cc) is used to help understand the cost of adding a new thread task and to know when it is worth it / not worth it to schedule additional work.  For example, it seems that for small (1000) task sizes we start to lose the benefit of threads in as few as 2 threads.

However, this benchmark is actually demonstrating a worst-case scenario in terms of "scheuduling" overhead.  Without changing the thread pool implementation at all we can considerably improve the efficiency of this benchmark.  This Jira is to add an alternative best-case scenario to better help understand the cost of new thread tasks.

**Reporter**: [Weston Pace](https://issues.apache.org/jira/browse/ARROW-12903) / @westonpace
#### PRs and other links:
- [GitHub Pull Request #10421](https://github.com/apache/arrow/pull/10421)

_{**Note**: *This issue was originally created as [ARROW-12903](https://issues.apache.org/jira/browse/ARROW-12903). Please see the [migration documentation](https://github.com/apache/arrow/issues/14542) for further details.*}

Start in thread_pool_benchmark.cc with the existing ThreadPoolSpawn benchmark and understand how its task sizes and thread counts expose scheduling overhead. Add the alternative best-case benchmark described in the issue, then compare its results with ThreadPoolSpawn to confirm the scheduling bottleneck is represented.

Written by the indexing model from the issue text.