This fixes the problem when config keys collide with Kernel/Object
methods (private). An example is `exec` which is used in vagrant-exec
plugin.
Compare:
> old.send :exec
ArgumentError: wrong number of arguments (0 for 1+)
> old.public_send :exec
=> #<Vagrant::Config::V2::DummyConfig:0x007fe212cc05c8>
This is done by calling the `upgrade` method on the _old_ configuration
classes. The old configuration classes are given the complete new
configuration and can set whatever settings they need to on it.
Before we were manually going over every plugin and getting each piece,
all over the place. Now we have a central manager that will give us all
the pieces we want. There is still some cleanup to do here but this is
much better overall.
The basic process for this is to:
1. Load the configuration using the proper loader for that version. i.e.
if you're loading V1 config, then use the V1 loader.
2. If we just loaded a version that isn't current (imagine we're
currently at V3), then we need to upgrade that config. So we first
ask the V2 loader to upgrade the V1 config to V2, then we ask the V3
loader to upgrade the V2 config to V3. We keep track of warnings and
errors throughout this process.
3. Finally, we have a current config, so we merge it into the in-process
configuration that is being loaded.
This moves out the concept of a "default VM" from the Environment class
and makes it the responsibility of the V1 configuration that at least
one VM is defined on it. This lets the configuration ultimately decide
what a "default" implementation is.
This is useful so that it can take a look at the final loaded
configuration object and possibly make some tweaks to the configuration
object. The use case this was built for was so that config V1 can verify
that there is always at least a single VM defined as a sub-VM, the
"default" VM.
Previously, all procs were assumed to just be the current version. This
is certainly not going to be true always so now the version number of
the configuration must be explicit if you're assigning a proc to the
configuration loader.
This means that the Config::Loader now only knows how to load
configuration for versions used to initialize the class. This lets
things like the tests be completely isolated from what the actual
configuration is for Vagrant. This will be immensely useful to verify
that the loader functionality works for non-trivial bits (like
upgrading) without depending on Vagrant's upgrading functionality.
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.
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.
