Make ThreadPool resizable (i.e. change number of threads at runtime)

[Finii]

This is all in all rather lazy and does not allow to jump up and down in number of really running threads. But I guess it is ok.

One could in principle make it less lazy if the number of threads increases (and try to schedule all pending Tasks). Not sure if that is needed. I guess not - well, therefor I omitted it.

Maybe look at the diff commit by commit.

Fixes: #80

[Finii]

I am not a big fan of "lazy" thread creation, however. One of the big advantages of a pool is that the threads are already there and can pick up work immediately without the overhead of creating a thread. At least it would be nice to have a selector (e.g. gul14::SpawnThreads::immediately/lazy) in the constructor and in the set_max_threads() call. This way we could leave the choice to the user.

Please have a look at my half-lazy-half-eager implementation idea, described in the git commit message.

• The number of threads given in the ctor is created eagerly.
• The new number of threads given by set_max_threads() is created (ramped up) lazily.

[alt-graph]

I am neutral on this MR. I do not see a huge benefit in the lazy thread creation, only a marginal one. On the other hand, I think that adding it makes the interface easier to misuse accidentally – people will spin up threads that they did not really want yet and incur penalties for starting up threads they assumed to be there already. If we had more explicit control over this, maybe in the constructor, I could be convinced to a WF. But if @Finii and @soerengrunewald think that this is useful as-is, I won't stand in the way either.