provisioners/ansible: force --connection=ssh

When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.

In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.

Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.

With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.

ref #3900, #3396
provisioners/ansible: change arguments arrangement

- force `--connection=ssh` (any other modes like paramiko or smart are not
  supported)
- give the highest priority to `raw_arguments` for sake of simplicity (in
  usage, in code and in documentation)
- fix position of the `--limit` argument (the generated inventory could be
  shadowed by `raw_arguments`, while ansible.limit was able to override
  `raw_arguments`

ref #3396
provisioners/ansible: don't read/write known_hosts

Like Vagrant's default SSH behaviors (e.g ssh or ssh-config commands),
the Ansible provisioner should by default not modify or read the user
known host file (e.g. ~/.ssh/known_hosts).

Given that `UserKnownHostsFile=/dev/null` SSH option is usually combined
with `StrictHostKeyChecking=no`, it seems quite reasonable to bind the
activation/disactivation of both options to `host_key_checking`
provisioner attribute.

For the records, a discussion held in Ansible-Development mailing list
clearly confirmed that there is no short-term plan to adapt Ansible to
offer an extra option or change the behavior of
ANSIBLE_HOST_KEY_CHECKING. For this reason, the current implementation
seems reasonable and should be stable on the long run.

Close #3900

Related References:

- https://groups.google.com/forum/#!msg/ansible-devel/iuoZs1oImNs/6xrj5oa1CmoJ
- https://github.com/ansible/ansible/issues/9442
provisioners/ansible: improve comment wording

Get rid of the Joker, thanks to @maspwr :)
Add base skeleton for `vagrant push`
Add preliminary File pusher (incomplete)
Accept an environment in the push config
Add Push to the PLUGIN_COMPONENTS
Accept a list of options in #push signature
Rename file push to noop push
Use a pushes registry instead of data hash
Add #length and #size methods to Registry
Make Registry enumerable

Registry already responds to #each, so including the Enumerable module
gives us nice methods like #select and #collect fo' free!
Add Registry#empty? to check if a registry has any items
Do not use Enumerable in Registry

Calling methods like #first in Registry is misleading because it returns
a different result than registry.get(registry.keys.first).
Add Push command and tests
Super primitive implementation of Environment#push
Push does not have access to @machine
Make Environment#pushes its own method
Ignore options that come back from the plugin for now