Feat: add support for ssh

[glpatcern]

This PR is stacked on top of #307 and defines support for an ssh protocol, either for remote access (e.g. via sshfs) or as a data transfer protocol via scp. Fixes #277.

In the process of writing it, I realized that the Draft did not include any explanation of the Response payload of a share (!), so that's included as well with a separate commit, which I'd like not to squash when the PR gets merged.

An important issue when dealing with ssh/scp is that a local account for a remote user at the sharing server end has to be used, at variance with web-based protocols where remote users do not require it. @sunetfreitag how is FileSender going to approach this?

[mickenordin]

Yes, very good.

[MahdiBaghbani]

This is a good addition!
I wonder if the wrong response payload (code 200?) should result in red status in the OCM Stub tests

[glpatcern]

This is a good addition! I wonder if the wrong response payload (code 200?) should result in red status in the OCM Stub tests

Well, it should indeed! Maybe "orange" if you have such a concept

[glpatcern]

I've rebased this and made it clear that for ssh access we need a full address in the form [email protected]:port/resource/path. Whether the username is receiver-specific or totally generic (similar to [email protected]) is left to the implementation.

[mickenordin]

Ok, good, I started to implement this in amity and figured out I had to have a complete virtual file system if all I had was the public key to distinguish between shares, since that may well be reused between multiple shares across multiple users. Now, that turned out pretty good, so I may keep it, but at least now we don't need to do it that way :)