(PUP-2014) Make module use current_environment

Module now uses current environment instead of configured
environment when being asked for a module and not supplying
an explicit environment name. It used to lookup to configured
environment giving invoking logic no chance to modify the
default without modifying the setting.
(PUP-2214) Make util rdoc and related parser use :current_environment
(PUP-2214) Add comment about looking up environment for requests.
(PUP-2214) Change autoloader to use current_environment for changed?

This changes the autoloader to use the current_environment as the
environment when performing a changed? operation. (It used to check
if the configured environment was changed).

The complicated bootstrap support still uses lookup of configured
environment as that is the fallback when booting.
(PUP-2214) Add comment what command_line "current_environment" means
(PUP-2214) Add comment about application's use of configured env
(PUP-2214) Add comment about module_tool's lookup of requested env
Merge pull request #2623 from jpartlow/issue/master/pup-488-add-tests-for-resource-meta-parameter-access

(PUP-488) Add specs fur future Resource parameter/metaparameter access
(PUP-2369) Update Solaris acceptance to ignore 'of type <class>'

Another block of Solaris acceptance tests needed their property change
assertions updated to ignore the 'of type <class>' info that was added
by PUP-2369.
(PUP-1597) Handle containment of relative names

The contain() function made an error when dealing with a relative name.
It assumed that the class that was actually included was always the same
as the name that it was given. In many cases this is true, but when the
name is found via a relative lookup (e.g. contain(bar) inside a class
foo, when a foo::bar exists), the assumption breaks down. The source of
the problem is that it tries to look up the included class after the
fact. Without all of the extra information about namespaces it isn't
able to find the right class.

To fix this, the include() function has been updated to return the
class resources that it included (including those that were already
present). This allows the contain() function to create the appriate
edges with the exact resources needed.

A secondary change in this was to remove the checks for include not
being able to include a class. The compiler method that is involved
already makes that check and raises an error, so the include functions
code was simply redundant.
(PUP-1597) Separate different modes of including

The evaluate_classes method has a couple different responsibilities and
inputs. This is just an attempt to pull them apart some and make the
flows a little more straightforward.
(PUP-2339) Modify $GEM_SOURCE for CI bootstrap

It is preferable to override the authoritative source (rubygems.org)
with our own internal resources, as opposed to the other way around.
This change ensures that if $GEM_SOURCE is set in the environment,
it is honored. Otherwise, we fall back to the public authority,
rubygems.org.

This change is analogous to the following line in our Gemfiles:

    source ENV['GEM_SOURCE'] || "https://rubygems.org"
Merge branch 'stable'
(maint) Update beaker to 1.11.0

With beaker 1.10.0 (and probably any earlier version that included the
dependency on google-api-client), we started seeing this error:

/usr/local/opt/rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/bundler-1.5.2/lib/bundler/rubygems_integration.rb:250:in `block in replace_gem': can't activate jwt (~> 0.1.4), already activated jwt-1.0.0.

This issue is discussed in https://tickets.puppetlabs.com/browse/QENG-655,
and it appears to be addressed by beaker 1.11.0.
Merge branch 'stable'
(maint) Reduce resource lookup

scope.resource was called multiple times. Even if this is a simple
method, it is still a method call and is slower than just holding onto
the result. This also removes some comments that appear to be out of
date.
(PUP-1028) Specify various ways of matching nodes

There were no tests that tried to specify how node statements are
selected. This adds coverage for various ways in which a node statements
can match a given node object and varifies that the future evaluator and
the current evaluator produce the same results.

There are 2 cases where the future evaluator isn't able to handle the
same node statements: using numbers. One case, where a name begins with
a number, seems completely reasonable. The other case, where the name is
a valid number, seems like an arbitrary restriction and so we need to
discuss.
(PUP-1028) Improve grammar for node expression to accept numbers.

It was previously not possible to enter a name consisting of just
a number, or where one name part was a number.

e.g.
1.2.3.4
hello.1

This grammar change fixes this problem. Note that any segment must be a
valid name or valid numeric string. Also note that white space is
ignored.
Merge pull request #2553 from duritong/fix/master/argument_error

(PUP-2303) Fix arguments of ArgumentError
(PUP-2182) Add virtual_packages feature to package type.

In 3.5.x, the yum package provider changed to accept virtual package
names (packages that provide other package names).

That change in behavior caused some undesirable side-effects. As we did
not give users fair warning that this behavior was changing, we have
decided to change the yum provider back to only accepting "real" package
names by default.

To keep the support for virtual package names, a "virtual_packages"
feature has been implemented on the package type and supported on the
yum package provider.  The feature adds the "allow_virtual" parameter
that controls whether or not virtual package names will be allowed for
install/uninstall.

For now, the default value for this parameter will be false to restore
the previous behavior.  However, a deprecation warning will be issued to
let users know that the default will eventually be changed to true.
Users can prevent the deprecation warning by explicitly setting the
parameter to either true or false.