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, you must be able to deploy to it, because otherwise you wouldn't be able to ssh to it to add the key.

BTW, there are also some security implications here. For instance, I currently use the none backend to manage machines from a machine that doesn't have their private keys, but instead uses the SSH agent. So a compromise of the central machine doesn't necessarily lead to a compromise of the others. But if you generate new private keys on the central machine, that's no longer the case.