Log reporting of unexpected FAILURE status responses from SFTP server

(continuation of [ Paramiko server responds to stat() with FAILURE rather than NO_SUCH_FILE #817](https://github.com/hierynomus/sshj/issues/817))

Various servers respond to requests with FAILURE instead of responding (as suggested in the standard) with a more specific error.

Examples are:
SSH2-paramiko responds to stat() with FAILURE instead of NO_SUCH_FILE
SSH2-OpenSSH responds to mkdir() with FAILURE instead of FILE_ALREADY_EXISTS
I am sure there are many others.

Much time and effort is needed to reach this conclusion, as the data are currently buried in a torrent of debug and trace logs, which are not always easy to obtain (it took me 12h to diagnose the first example (with some help from @vladimirlagunov, for which thanks).

There was an prior issue regarding the verbosity of SSH4J logs, [logs are too chatty for a library #80](https://github.com/hierynomus/sshj/issues/80), at the issue of which @shikhar made the log reporting level "debug" for most (all?) log events.

It is proposed here to consider this kind of weak compliance with the standards as an ERROR, so that it will automagically appear in the application logs in a very visible way. NOTE that in the case of compliant servers (or those for whom fixes have been created - in the sense of [ How best to deal with servers responding FAILURE rather than a more specific status #821](https://github.com/hierynomus/sshj/issues/821) ) - this should never happen.

In addition, it is proposed to provide all contextual information necessary to fixing the problem in that log line, so that a fix may be implemented as quickly as possible.