A failed SFTP upload is not recognized correctly

When using a remote linux deployment configuration and In case an SFTP upload fails (no rsync available on the remote device), a failure during the upload is not recognized anymore. I think the commit changing this behaviour was

7cca6cd718baa6ee7501e7dfde514591d4fa61f7
FileTransfer: Make the usage more convenient 
Prepare the API for rsync implementation.

I guess the reason why it is handled this way, is that sftp returns exit code 1 even only an mkdir operation failed because it already exists. As far as I read the previous implementation the mkdir operations were handled separately in the past. Now all errors during SFTP upload because of e.g. file busy, r/o filesystem, etc. are silently ignored. Not verified it in detail, but I think the cached upload timestamps are still updated, so the need to upload the changed files is also not considered anymore, if the error reason (e.g. filesystem has been remounted r/w)  has been fixed in the meantime.

This results in a lot of strange errors, when e.g. one wants to remote debug an executable that is not in sync with the host binary.

I just did a quick debug session for QtCreator under Linux. An easy fix(but maybe not cross-plattform, actually not sure what is called for sftp under Windows/Mac), would be to filter out mkdir errors from the m_errorString in SshTransferInterface::handleError(), and if no errors are left, set the exit code to 0.

Then in the GenericDirectUploadService::GenericDirectUploadService constructor change the lambda function from:

if (result.m_error != QProcess::UnknownError) {

to

if (result.m_error != QProcess::UnknownError || result.m_exitCode != 0) {

This way, SFTP errors unrelated to mkdir errors are still considered correctly.