Make it simple to decide when to `connect` and `start`

[AndrewRadev]

This is a continuation of a comment thread in #19.

Currently, the connect call accepts a :start => true option, which starts a new Vim instance if the Server couldn't connect. I believe a better way to do this is to provide the following method calls:

• Server#connect: waits for :timeout seconds, returns nil if no Vim server was found.
• Server#connect!: waits for :timeout seconds, raises an exception if no Vim server was found.
• Server#running?: checks if a Vim with the given servername is currently running
• Vimrunner#connect(name) and Vimrunner#connect!(name) -- for convenience

This would allow a workflow like the following:

# Long form, flexible
server = Server.new(:name => 'FOO')
client = server.connect

if not client
  puts "Couldn't connect to an existing Vim, starting server"
  client = server.start
end

# Short form, quick and easy
server = Server.new(:name => 'FOO')
client = server.connect || server.start

# We are certain a Vim has been started, raise an exception if that's not the case
server = Server.new(:name => 'FOO')
client = server.connect!

I still need to write some tests and think about eventual problems. I also think it may be a good idea to do one of the following:

• Remove a lot of options from the initializer and put them on start. Problem: this will make the Server object itself practically stateless, potentially causing complications.
• Make a different server class for connecting (ExternalServer?). Problem: it may be inconvenient for some workflows.
• Document the caveats in connecting to an existing server -- many of the options may be ignored.

I'm currently leaning towards the third option, since it seems the safest one, but I'd say it's important to at least explore some of the possibilities and consider modifying this in the future.

I'll try to finalize this the coming weekend and release a new version. Feedback welcome.

[AndrewRadev]

I just released version 0.3.0 with the described changes and some other stuff that was in the pipeline. With this, I consider the issue closed for now.