Confront the QFuture and QtConcurrent API with Creator utils

After latest changes to QtConcurrent and QFuture / QPromise it would be good to compare what we have in Qt with what we have in QtCreator. Especially:

src/libs/utils/runextensions.h
src/libs/utils/mapreduce.h

Ideally, Qt API should be sufficient to do all what is done in the above headers, so that QtCreator don't need anymore to have its own tools and can use directly what Qt provides. This would also be a good test for the Qt API, confirming it's comprehensive enough.

***

Start of analysis:

1. QtConcurrent::run() and QtConcurrent::runWithPromise compared to creator's API is missing the following:

1.1 priority argument

This should be done quite easily, by adding overloads to run and runWithPromise. However, wondering also about the fluent interface, introduced recently into Qt 6 - maybe it would be sufficient to add it only there, just to avoid overloads multiplication.
Anyway, QTaskBuilder doesn't work now with runWithPromise(), so maybe it's worth to add it first.

1.2 stackSize argument

I'm wondering if anything special is really needed. User may configure his own QThreadPool, by setting the maxThreadCount and stackSize and may pass it to run() or runWithPromise() overload that accepts custom threadPool.

1.3 onResultReady() / onFinished() handlers

Looks like these handlers have very simple implementation employing QFutureWatcher for the passed QFuture. So, for the scope of creator usage, we don't need to provide anything special from Qt side, since these simple handlers may stay in creator's codebase.

1.3.1 onResultReady() handler

We are lacking it right now I guess.

1.3.2 onFinished() handler

Looks like we have currently QFuture<T>::then() functionality, which seems like serving the same purpose. A handler passed to then() may accept alternatively the original future, so multiple results in then() may be accessed inside handler, like in onFinished().

A future returned by runWithPromise() may be used as a starting point in the chain, however, we are not getting access to then()'s promise, so we are not so flexible in "thens" as we are in the starting runWithPromise. For API completeness it looks like we are missing the continuation which would accept the QPromise &, like inside runWithPromise().

Added https://bugreports.qt.io/browse/QTBUG-87072 for it.

2. QtConcurrent::mapped() and friends:

... to be continued ...