(#22128) Confine yum provider prefetch spec from running on windows

The new yum prefetch spec was failing on windows:

Puppet::Type::Package::ProviderYum prefetching injects latest provider
info into passed resources when prefetching
    Failure/Error: myresource = package_type.new(:name => "myresource",
:ensure => :latest)
    Puppet::ResourceError:
      Parameter ensure failed on Package[myresource]: Provider must have
features 'upgradeable' to set 'ensure' to 'latest'

possibly because the windows default package provider does not provide
the same features.  Since this test is specific to yum, confining it from
running on windows.
Merge pull request #1834 from jpartlow/issue/master/22128-yum-prefetch-failure-spec-confined-on-windows

(#22128) Confine yum provider prefetch spec from running on windows
Merge pull request #1835 from zaphod42/maint/master/fix-path-on-windows

(Maint) Fix testing path on windows
(#22128) Yum prefetch spec ensures use of yum provider

The prefetch spec for the Yum package provider was failing on platforms
whose default providers did not have the same capabilities (definitely
on Windows for msi), because the previous implementation was generating type
instances of Puppet::Type::Package without setting their providers.
Consequently these instances were being generated with references to the
platform's default providers, and might fail to set :ensure =>
:latest due to missing capabilities.

The spec is changed to associate instances of yum providers with the
package type instances being passed into prefetch.  Also removed the
confine for Windows.

This also clears up a typo that got through in the original patch, which
was failing on only some platforms.
Merge pull request #1837 from jpartlow/issue/master/22128-yum-prefetch-failure-solaris-spec-fix

(#22128) Yum prefetch spec ensures use of yum provider
(#18508) Extract class to control generating resources

The logic for determining how to add generated resources into the
catalog was tightly bound with the rest of the transaction code. This
makes it hard to test the exact logic around that. By extracting a class
it exposes that logic in a much more testable form.
(#18508) Ensure eval_generated resources apply at the right time

Resources created with eval_generate need to apply with the same
priority as their parent resource.
(#18508) Handle duplicate generated resources correctly

When a generated resource duplicates a resource already in the catalog,
we want to avoid adding it a second time, but we still want to create
dependencies between the resource and the generating resource. For
example, we may have a recursive file resource, but explicitly model one
of the files that will be generated. We still want the explicit file
resource to depend on its generated parent directory.

This also refactors the resource generation methods, splitting them up
into smaller methods.
(#18508) Ensure that no two resources have the same priority

The underlying red-black tree that is used as the priority queue for
tracking what resources to evaluate will only allow a single value per
key. This means that when generated resources are added they need to get
unique priority keys. However there could be an arbitrary number of
these resources added in between existing resources. This commit
provides a Puppet::Graph::Key that behaves like the numbering scheme of
an outline so that priorities can be arbitrarily nested and the nested
priorities are between the priorities at the outer level.

The integration tests for the file type caught this error. It only
showed up when 2 unique, new resources are generated.
(Maint) Move most graph related code to Puppet::Graph

We often talk about "the graph", but until now there hasn't been a clear
graph that we were talking about. The relationship graph that is used
for evaluation is the best candidate to fill this role, since it
contains all of the ordering information that is needed.

This also removes Puppet::Util::Graph, which was unused.