Use dedicated SSH keypair for "none" backend.

This should make the "none" backend a bit more useful as we only need to provide a key _or_ passphrase on machine creation and from thereon we only use the SSH keys within NixOps' state database.

If you have a large set of "none" machines and want to export/import them, this should no longer require to move around `ssh_config`s or even entries in your hosts file.

In addition, this fixes the situation where you need to build on the target machines and the none backend wasn't able to provide a private key for the to be generated `nix.machines` file.

VM test result: https://headcounter.org/hydra/job/nixops/none-improvements/tests.none_backend/latest
(also required fixing the VM tests)

This is related to #200 and after talking to @joelton on IRC it turned out he was on Darwin, so NixOps was trying to build on the target machine(s), which in turn requires explicitly specifying a private key. As we now have the keypair in our own db, this is no longer an issue.
Well, the machine is "created" like this:

![graph](https://chart.googleapis.com/chart?cht=gv:dot&chl=digraph{overlap=false;splines=true;agent-%3Efirst_ssh[style=dashed];password-%3Efirst_ssh[style=dashed];first_ssh-%3Emachine[label=%22copy%20id%22]{edge%20[label=%22use%20internal%20ssh%20key%22;color=red];machine-%3E%22nixops%20deploy%22;machine-%3E%22nixops%20ssh%22}})

Of course the SSH private key resides in the deployment specification, but using plain `ssh` without relying on `ssh_util` does have the advantage that we don't need to rely on the configuration of the host and as said: We even can use password auth for the first step.

I'm not sure I understand what you exactly mean by security implications, but for example if you use SSH agent forwarding it indeed will cause the key from the agent to be detached from the deployment. But IIUC the other backends provide their own SSH keypairs as well, so someone getting access to the state database (s)he will have access to all the machines anyway. So if that's a concern we could also encrypt the state database file.

That aside, if all our backends internalize the SSH stuff entirely, we could remove quite a lot of the cruft from `ssh_util`, for example handling of host keys and other factors (like for example the mentioned remote builds) that could get in the way of SSH operations. And of course, in order to protect the database, we could still encrypt it and/or the user could use external programs to do that on his/her own.

In the end, what I'd expect from NixOps is that no matter which deployment someone imports, you shouldn't need to configure additional things ("Please import this, then configure x, then you need to set y and some z and something over there. Oh, you're on OS X or cygwin, well... then you need ...") just to get it working.

Another option would be to make this an entirely different backend and we leave `none` as-is.