(PUP-2213) Read environment settings from other sections in config print

Puppet's config print functionality has a --section option to allow you
to read the configuration as it would be seen in other run modes such as
master or agent.  But the environment loaders are provided an
environmentpath and basemodulepath setting prior to Puppet evaluating
the user's --section setting, and will only provide environments as
configured in [main].  So if you have environmentpath set in master, a
`puppet config print modulepath --section master --environment
production` would show you the modulepath for the production
environment as loaded from [main] not [master].

To fix this, when handling a config print call, we are now overriding
the environment loaders with settings obtained from the user selected
section.  This means that the interpolated settings can now find an
environment from an environmentpath specified in any section of
puppet.conf.

The static environment loader get_conf() method is also changed to
return a simple configuration that just returns the statically declared
environment's settings.  This ensures that `puppet config print
--environment doesnotexist` will correctly print the 'no_manifest' and
empty modulepath setting that reflect the private statically configured
environment settings for a non-existent directory environment.
Merge pull request #2554 from jpartlow/issue/master/pup-2213-config-print-section-works-with-direnvs

(PUP-2213) Read environment settings from other sections in config print
(maint) Don't overwrite mast_opts hash

This test was resetting overwriting the master_opts hash being sent into
with_puppet_running_on, accidentally relying on the broken Beaker 1.7
behavior which would delete the cmdline args from the passed hash.  This
fix should allow this test to run with Beaker 1.8+
(PUP-2213) Expand paths for face/config spec on windows
Merge branch 'issue/master/pup-2213-expand-path-for-spec-on-windows'

* issue/master/pup-2213-expand-path-for-spec-on-windows:
  (PUP-2213) Expand paths for face/config spec on windows
Merge pull request #2556 from jpartlow/maint/master/fix-cmdline-overrides-environment-test

(maint) Don't overwrite mast_opts hash
(PUP-1060) Don't fetch latest versions at prefetch

In the previous implementation of yum .prefetch, package providers were
loaded and then the yumhelper.py script was used to determine the latest
versions available for all installed packages. While this worked for
simple cases, trying to support multiple combinations of enablerepo and
disablerepo flags makes this grossly more complex. In addition this
information is not needed at prefetch time, and testing the behavior in
prefetch gets messy.

This commit extracts the latest version query from the prefetch method.
It moves the logic to a method that does the actual querying and lazily
loads that data to keep the same run speeds. When multiple combinations
of enablerepo and disablerepo are added this information can be loaded
in the same fashion.
(PUP-1060) update yumhelper to handle {enable,disable}repo

In order to be able to use enablerepo and disablerepo flags while
ensuring latest, we need to be able to query for packages needing update
with a specific set of repos to enable and disable.

This commit updates yumhelper.py to take two flags '-e' for a repository
to enable, and '-d' for a repository to disable. The values given to
these flags must be a comma separated list of names with no spaces
between them.

It's unsustainable in the long run to continue extending this file, and
we should look very seriously at seeing what behaviors we can remove.
It's impossible to test this as-is and as we add more complexity we risk
introducing more bugs.

Original patch by Matthew Byng-Maddick.
(PUP-1060) Respect yum enable and disable repo flags

When a package resource is ensured => latest, the specific version
available will depend on what yum repositories are enabled and disabled.
Commit a4abf13d3 added the ability to pass arbitrary options to install
and update commands which allowed users to specify the --enablerepo and
--disablerepo options, but these flags would not be respected when the
latest package version was used. This meant that the latest version
found and the version that could be installed with the --enablerepo and
--disablerepo flags might differ, causing all sorts of bad things to
happen.

This commit resolves this issue by making the version query aware of
these flags. When a package checks for the latest version available, it
passes all repositories enabled and disabled to the update query.
Whenever an update query is made for the first time with a combination
of repositories that output is stored, so that only query for a given
combination of repositories is made.

Unfortunately, this change still relies on yumhelper to do the actual
querying. In the long run it would be good to use `yum check-update`
instead of the complex helper script so that we can actually test and
verify the code responsible for querying packages.