Allow status and ssh to run without a lock

[Sharpie]

Prior to this patch long running operations, such as provisioners, would prevent vagrant status or vagrant ssh from being run due to Vagrant action locking. Attempting such actions would result in an error message. This is inconvienant as shelling into a VM is a common debugging step in figuring out why a provisioner is taking longer than usual.

Vagrant 1.7 introduced the ability to mark certain actions as not requireing a lock. This patch adds lock: false to the get_state and get_ssh_info calls which allows both vagrant status and vagrant ssh to function while a long-running action is executing in another process. Vagrant 1.6 will ignore the unknown lock option and fail as usual.

[Sharpie]

Simple reproduction case:

Vagrant.configure('2') do |config|

  config.vm.provider :openstack do |p, o|
    # OpenStack configuration.
  end

  config.vm.define :test do |node|
    # Some long-running provisioner
    node.vm.provision :shell, inline: 'sleep 300'
  end

end

Run vagrant provision test in one terminal. Open a separate terminal and attempt vagrant status or vagrant ssh test. Both will fail with:

An action 'get_state' was attempted on the machine 'test',
but another process is already executing an action on the machine.
Vagrant locks each machine for access by only one process at a time.
Please wait until the other Vagrant process finishes modifying this
machine, then try again.

If you believe this message is in error, please check the process
listing for any "ruby" or "vagrant" processes and kill them. Then
try again.

[coveralls]

Coverage remained the same at 92.27% when pulling 44e4cce73bb6ca60fc3f5cd2073d073c21fc21ce on Sharpie:dont-lock-for-ssh into 88087367db434df92bedc2530745807c85e637c1 on ggiamarchi:master.

[ggiamarchi]

Good one, LGTM.