An old workaround for `std::allocator_traits<>::value_type` lints from
IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
Convert the workaround to use the same approach we already use for a
workaround of `std::__decay_and_strip<>::::__type` lints. Then update
the `<memory>` inclusions to follow the now-correct IWYU lints.
Don't pass the desired worker thread count to the `cmWorkerPool::Process()`
method but set it separately with the new `cmWorkerPool::SetThreadCount`
method. This allows calling `cmWorkerPool::Process()` repeatedly without
having to pass the thread count every time.
This factors out the concurrency framework in `cmQtAutoGeneratorMocUic` to a
dedicated class `cmWorkerPool` which might be reused in other places.
`cmWorkerPool` supports fence jobs that require that
- all other jobs before in the queue have been processed before the fence
job processing gets started,
- no jobs later in the queue will be processed before the fence job processing
has been completed.
Fence jobs are needed where the completion of all previous jobs in the queue
is a requirement for further processing. E.g. in `cmQtAutoGeneratorMocUic`
the generation of `mocs_compilation.cpp` requires that all previous
source file parse jobs have been completed.
