(#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
(#22191) Add cancelled resource handler

This commit adds the ability to pass a cancelled resource handler callback
to the traverse method such that if the traversal is cancelled, then the
callback is invoked once for each resource that is ready, but not yet
evaluated.

In addition, the resource is "finished", which unblocks its dependents, so
that the callback can handle those as well.

While writing tests for this, we found a bug in the main while loop.
Previously, the loop was removing the next ready resource, and then checking
if the loop had been cancelled. But if the loop was ever cancelled, the removed
resource was effectively lost. This commit reverses the order so that we only
remove the next ready resource if we intend to evaluate it.

Paired-with: Patrick Carlisle <patrick@puppetlabs.com>
(#22191) Mark ready, but unevaluated resources, as skipped

Previously, if a transaction was cancelled while processing resources, the
report did not contain any information about the skipped resources.

This commit modifies the transaction to supply a cancelled_resource_handler
callback, which if invoked, will generate a resource status object for the
resource, and mark the status as skipped.

This commit also updates the test helper to clear the run_status global
state before each test.

Paired-with: Patrick Carlisle <patrick@puppetlabs.com>
(#22191) Always process internal catalogs

Puppet generates and applies several catalogs during a single run. There is
the main (host_config) catalog, either downloaded from the master, or locally
applied. However, there are several other internally generated catalogs used
to manage internal state, such as file permissions from defaults.rb. Basically
anytime `Puppet::Settings.use` is called.

Previously, if puppet was asked to stop, `Puppet::Application.stop!`, then it
would cancel the current transaction, as well as any future transaction. As a
result, we may intentionally cancel the main (host_config) catalog, but then
unintentionally skip the transactions that follow, e.g. writing the rrdgraph
report.

This commit modifies the transaction to only cancel the evaluation loop if we
are evaluating the main (host_config) catalog and a stop has been requested.
All other internal catalogs will always be processed.
(#22191) Rename cancelled to canceled

Prefer the current American spelling from the past 30 years.
Merge branch 'ticket/master/22191-mark_skipped_resources'

* ticket/master/22191-mark_skipped_resources:
  (#22191) Rename cancelled to canceled
  (#22191) Always process internal catalogs
  (#22191) Mark ready, but unevaluated resources, as skipped
  (#22191) Add cancelled resource handler