Forcing ssh_wait is considered harmful.

1. If your Blimpfile is misconfigured, you'll not get any diagnostics information.
2. When you press Ctrl+C, blimpy doesn't exit because it's just ssh getting killed (and blimp ignores that)

There appears to be no provision for handling options, so I just made it a separate command
function like this touching ARGV is abstraction violation, as it prevents other driver code from legitimately launching interactive shell.

 Better to let the calling command handle this
allow monkey-patching of Blimpy by the project (mainly to add more commands)
don't waste a line if there's no need to

Blimpy prints unnecessary empty line if the SSH connection goes through
fast enough. Don't do it.
support a non-standard SSH port
debugger gem only works with 1.9 and forward
Merge pull request #73 from cloudbees/master

Bunch O changes
Adding multi-file scp
only works with Ruby 1.9+
SSH returns 255 for connection refused errors.

So limiting the range down a bit.
Making it work again with fog 1.10

in 1.9, the original code was sufficient, but 1.10 has a massive
refactoring in the way of registering providers. Unless at least one
provider is registered, the providers hash is empty, and it causes
an exception like the following:

/var/lib/gems/1.8/gems/fog-1.10.0/lib/fog/compute.rb:39:in `new': undefined method `include?' for nil:NilClass (NoMethodError)
    from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/boxes/aws.rb:39:in `fog'
    from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/boxes/aws.rb:32:in `validate!'
    from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/fleet.rb:110:in `start'
    from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/fleet.rb:109:in `each'
    from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/fleet.rb:109:in `start'
    from /home/kohsuke/ws/cloudbees/blimpy/lib/blimpy/cli.rb:73:in `start'
    from /var/lib/gems/1.8/gems/thor-0.18.0/lib/thor/command.rb:27:in `__send__'
    from /var/lib/gems/1.8/gems/thor-0.18.0/lib/thor/command.rb:27:in `run'
    from /var/lib/gems/1.8/gems/thor-0.18.0/lib/thor/invocation.rb:120:in `invoke_command'
    from /var/lib/gems/1.8/gems/thor-0.18.0/lib/thor.rb:363:in `dispatch'
    from /var/lib/gems/1.8/gems/thor-0.18.0/lib/thor/base.rb:427:in `start'
    from /home/kohsuke/ws/cloudbees/blimpy/bin/blimpy:24

By forcing the registration of a provider, it works against with fog
1.10. Looking at the source tree, this change should also work with fog
1.9.
Fixed a system/local conflict problem

If blimpy gem is already installed, this ends up picking blimpy from the installed gem, as opposed to the local workspace.
Fixing the unit test failure

Since these tests do not use any livery, explicit wait_for_ssh command
is required
If Blimpfile is invalid, report why
Merge pull request #74 from cloudbees/master

Fixed the test regression and then some
Revisiting 8b3800894c283cf34b8598731592770e22ebd984

(04:25:26 PM) rtyler: kohsuke: so `blimpy ssh` is going to return immediately now?
(04:25:41 PM) kohsuke: yes, it fails if ssh fails
(04:26:09 PM) ***rtyler is a bit confused
(04:26:14 PM) rtyler: this seems like a big UX change then
(04:26:21 PM) ***rtyler should read more carefully
(04:27:13 PM) kohsuke: Yes, modifying a test case made me wonder if there's a better way to do it
(04:28:00 PM) kohsuke: (though in practice you wouldn't see any change as "blimpy provision" does wait for ssh to come online)
(04:28:13 PM) rtyler: but a `blimpy ssh` won't log me into the machine?
(04:28:51 PM) kohsuke: I think just reporting ">> Connecting: SHIPNAME..." if the first attempt fails would be sufficient
(04:29:25 PM) kohsuke: The "gotcha" that made me write that patch is that my first attempt to use blimpy failed miserably at "blimpy ssh"
(04:29:51 PM) kohsuke: because it was trying a wrong user name, and I couldn't Ctrl+C it because of another bug that since then I fixed
(04:30:11 PM) rtyler: with aws and openstack it connects multiple times, usually the machine isn't accepting ssh connections right away
(04:30:14 PM) rtyler: especially on a fresh image
(04:30:25 PM) kohsuke: yes, I understand why you wrote it the way you did the first place
(04:31:17 PM) rtyler: heh
(04:31:21 PM) rtyler: alright
(04:32:05 PM) kohsuke: Let me change it to ">> Connecting: user@SHIPNAME:port" with dots added over time,
(04:32:15 PM) kohsuke: and if it's killed by SIGINT I'll run ssh one last time but without -q
(04:32:22 PM) kohsuke: so you see the error message
(04:32:41 PM) kohsuke: does that sound OK to you?
(04:34:30 PM) rtyler: that does sound good

It turns out some mode of failure includes ssh hanging (such as trying a
wrong port), so silently re-running SSH again wasn't very wise. Instead,
show the command line needed to let the user run the ssh command by
himself.
Revert "Fixing the unit test failure"

This reverts commit 882730729638f7f613b05f9291c32e691b162dac.
Merge pull request #75 from cloudbees/master

Reverting wait_for_ssh command
Intro the show command for future details (tags for now)
Intro .provision_on_start flag for ships

Allows control over when the livery provisioning happens for
ships. This was needed because sometimes we don't want to
provision (Puppet) until all ships are up and we know their
hostnames in AWS, etc.