[5cript]

Part of #260.

ProcessingThread no longer accepts tasks after stop() (until the next start()) or after a task threw, and a refused or dropped promise task completes its future with an error value instead of a broken promise. Before, such tasks ran later in the destructor on the destroying thread, or never ran while their callers waited on them.

• The stop flag is set and checked under the task mutex and stop() drains outside it, so a push racing stop() is either run by the drain or refused. A promise task refused during the drain completes once the drain reached it, so it still works as a barrier for the tasks queued before it.
• pushPromiseTask takes an optional unfinished result. UnfinishedTaskResult provides it for void (nothing), bool (false) and std::expected of SftpError (TaskPushFailed) or OperationError (ChannelClosed). A finalized strand answers the same way instead of with a runtime_error.
• After a task threw, queued tasks are dropped and their futures complete with that error. workQueue then fails the operations that need the strand, one per cycle, instead of blocking in get().
• Strand final tasks are cleanup tasks: they still run when the loop fails, and after stop() on the calling thread, which acts as the processing thread meanwhile, so SftpSession::close and Channel::close keep removing themselves. The drain and these caller-side runs contain task exceptions like the loop does.
• removePermanentTask from another thread during a permanent cycle returns whether it removed the task, not whether the deferred removal ran.
• Session::createPtyChannel and createSftpSession go through pushPromiseTask, and FileStream::readAll and a chunked FileStream::write complete with TaskPushFailed when a read or chunk cannot run (FileNull on a closed file).