fix typo in change_host_name
Setting up hostname before setting up the network to minimize issues as described in http://serverfault.com/questions/38114/why-does-sudo-command-take-long-to-execute
Update CHANGELOG
Log the guest class chosen
Merge pull request #931 from hollow/master

typo in change_host_name
Update CHANGELOG
Foundation for supporting multiple version types

I created VersionBase which is the abstract base class for any
configuration versions. Configuration versions are responsible for
knowing how to load configuration given a proc (from a
Vagrant.configure block), as well as merging configuration procs. In the
future, it will have to upgrade versions as well. This is not done yet.

The VERSIONS constant was added to Vagrant::Config which is a registry
to keep track of all the available configuration versions. The
VERSIONS_ORDER constant is an array of the ordering of these versions.
The ordering is important so that in the future Vagrant can attempt to
gracefully upgrade the configurations. It is also used to determine the
current configuration version (which is assumed to be the last version
in the order).

The loader was modified to use the current version and the VERSIONS
registry instead of hardcoding V1.
Vagrant.configure and versioned configuration

Vagrant.configure is now how configuration is done in Vagrantfiles
(previously it was Vagrant::Config.run). This function takes a single
argument which is the version of configuration to use.

Various internals were updated for this new versioned configuration.

Note that multiple versions of configuration aren't yet used so aren't
fully supported by Vagrant, but the foundation is being set here.
Built-in config should use the new Vagrant.configure.
Plugin activation

Vagrant is only guaranteeing that the plugin definition superclass (the
Vagrant.plugin("1") part) is backwards compatible. Anything else, such
as Vagrant::Command::Base and so on, will likely change in future
versions. Beacuse of this, plugins should only immediately expose their
definition.

In order to support loading the other classes, plugins should defer
loading to the "activation" phase of a plugin. This can be done using
the `activated` block:

    class MyPlugin < Vagrant.plugin("1")
      name "my plugin"

      activated do
        require "myplugin/my_command"
      end

      command("foo") { MyCommand }
    end

Plugin activation is done at two specific times:

  * Right when a Vagrant::Environment is created and the global plugins
    (such as from ~.vagrantrc) are loaded.
  * Right before loading configuration, but after the Vagrantfiles have
    been evaluated. This allows plugins to be defined within these files
    as well.
Convert all command plugins to use the new `activated` block
config.ssh.shell now contains full shell command

Before, it only contained the shell executable and "-l" was magically
appended to it. However, every shell doesn't support "-l" and maybe "-l"
isn't even the behavior that users want!

Therefore, the config.ssh.shell command must now contain the full
command to execute.
Get rid of autoload use in Guests

I don't use `activated` here because I'd really like to optimize
performance as much as possible, and loading files from disk is
generally slow. So instead of using `activated` I load the file at the
last possible moment which is when the exact class is being requested.

I don't think many people will do this outside of the core, and I'm not
too concerned.
Get rid of autoload in hosts plugins
Change kernel plugin to use `activated` block
Remove autoload from provisioners plugins
Defer loading for commands to last possible moment
add workaround for ubuntu precise not properly loading routes
Merge pull request #947 from justinlynn/add_dhcp_default_route_option

add workaround for ubuntu precise not properly loading routes from dhcp
On Linux where IPv6 is disabled, where /etc/hosts has '::1 localhost', a socket connect to localhost 2222 results in ENETUNREACH which needs to be caught as per this patch.