When destruction starts or the pool size is reduced, only the last worker thread could in fact stop, while the other workers that should stop would enter a busy wait state, since the condition they are waiting for via a condition variable would be satisfied. The busy waiting threads could starve the last thread from CPU, delaying downsizing or shutdown. This is particularly noticable when running via Valgrind; shutdown delays in the order of tens of seconds have been observed. Fix it by making each thread stop as soon as it can. Doing this required adjusting the management of the workers vector: - When a worker is stopping, it may not yet be possible to downsize the vector (if it is not the last worker). In that case an invalid thread entry is left in the vector, and the vector will be downsized when possible as other threads stop. - When upsizing, some threads above the current limit may still be running (if there was a recent downsizing and they haven't stopped yet). Such threads just keep running.

Fix livelock during shutdown and downsizing.

This is a change of semantics for the `enqueue()` function. If it would block, it returns ready `future` instance with `would_block` exception.