(#22205) Extract class for generating resource priorities

Previously the code for generating priorities was scattered throughout
the places that needed to add vertices to the relationship graph. This
pulls out that logic into a class that can generate the priorities for
resources, and those contained in other resources. This is needed to be
able to make this strategy pluggable.
(Maint) Removed commented out settings

These settings were commented out. I think we have already done
something else to support those use cases, and if we haven't...well,
that is what version control is for.
(Maint) Restructure requires for settings

The settings classes were not loaded in a robust manner. Some required
other files with the knowledge that the right modules would be created.
This caused a duplication of requires (which can cause a small slowdown
as ruby looks up whether the code has already been loaded). By requiring
the settings *after* the settings class has been opened, we can avoid a
lot of this extra work and overhead.
(#22205) Add enum setting type

It is often useful to be able to restrict the valid values for a setting
to a known set. This adds an :enum setting type that can take a :values
array, which defines the allowed values. If the value given for the
setting is now found in the list of allowed values, then it will throw
an error.
(#22205) Provide setting to control manifest ordering

The default ordering for manifests is something that is useful to be
able to control. This provides an setting that will be used to select
between the pre-#18508 and post-#18508 ordering mechanism.
(#22205) Re-introduce old ordering as a Prioritizer

This creates an old prioritizer for resources as it existed in commit
f51e967b73ff0154801f514aff40ca524bdd8ab1.
(#22205) Chose a Prioritizer based on Puppet[:ordering]

This ties the selection of the Puppet::Graph::Prioritizer to the
Puppet[:ordering] setting. In order to make it easier to ensure that all
of the uses of the prioritizer use the same one (because it needs to
track state) this also moves around the relationship of the catalog and
the transaction. Previously the catalog was responsible for converting
itself into a relationship graph. This now puts that responsibility on
the transaction, which much now be constructed with the desired
Prioritizer. The selection is still done in the catalog (because that is
where #apply lives, which is the public starting point of applying a
catalog).

Additionally this adds a random prioritizer.
(#22205) Extract common Prioritizer code into a superclass

All of the prioritizers had the same code to track priorities already
produced. This pulls that into a superclass.
Merge pull request #1840 from zaphod42/feature/master/22205-setting-to-control-default-ordering

(#22205) Provide setting to control manifest ordering