New protocol: PROT_SSHCONN, bare ssh-connection.

This is the same protocol that PuTTY's connection sharing has been
using for years, to communicate between the downstream and upstream
PuTTYs. I'm now promoting it to be a first-class member of the
protocols list: if you have a server for it, you can select it in the
GUI or on the command line, and write out a saved session that
specifies it.

This would be completely insecure if you used it as an ordinary
network protocol, of course. Not only is it non-cryptographic and wide
open to eavesdropping and hijacking, but it's not even _authenticated_
- it begins after the userauth phase of SSH. So there isn't even the
mild security theatre of entering an easy-to-eavesdrop password, as
there is with, say, Telnet.

However, that's not what I want to use it for. My aim is to use it for
various specialist and niche purposes, all of which involve speaking
it over an 8-bit-clean data channel that is already set up, secured
and authenticated by other methods. There are lots of examples of such
channels:

 - a userv(1) invocation
 - the console of a UML kernel
 - the stdio channels into other kinds of container, such as Docker
 - the 'adb shell' channel (although it seems quite hard to run a
   custom binary at the far end of that)
 - a pair of pipes between PuTTY and a Cygwin helper process
 - and so on.

So this protocol is intended as a convenient way to get a client at
one end of any those to run a shell session at the other end. Unlike
other approaches, it will give you all the SSH-flavoured amenities
you're already used to, like forwarding your SSH agent into the
container, or forwarding selected network ports in or out of it, or
letting it open a window on your X server, or doing SCP/SFTP style
file transfer.

Of course another way to get all those amenities would be to run an
ordinary SSH server over the same channel - but this approach avoids
having to manage a phony password or authentication key, or taking up
your CPU time with pointless crypto.

doc/config.but

@@ -22,13 +22,26 @@ filled in before PuTTY can open a session at all.
 address}, of the server you want to connect to.
 
 \b The \q{Connection type} radio buttons let you choose what type of
-connection you want to make: a \I{raw TCP connections}raw
-connection, a \i{Telnet} connection, an \i{Rlogin} connection, an
-\i{SSH} connection, or a connection to a local \i{serial line}. (See
-\k{which-one} for a summary of the differences between SSH, Telnet
-and rlogin; see \k{using-rawprot} for an explanation of \q{raw}
-connections; see \k{using-serial} for information about using a
-serial line.)
+connection you want to make: an \i{SSH} network connection, a
+connection to a local \i{serial line}, or various other kinds of
+network connection.
+
+\lcont{
+
+\b See \k{which-one} for a summary of the
+differences between the network remote login protocols SSH, Telnet and
+Rlogin.
+
+\b See \k{using-rawprot} for an explanation of \q{raw}
+connections.
+
+\b See \k{using-serial} for information about using a serial line.
+
+\b The \q{Bare ssh-connection} option in the \q{Connection type} box
+is experimental, for specialist uses, and servers for it are not
+widely available.
+
+}
 
 \b The \q{Port} box lets you specify which \i{port number} on the
 server to connect to. If you select Telnet, Rlogin, or SSH, this box