(maint) Add pry to Gemfile as a development dependency

Without this patch it's difficult to do interactive debugging and
introspection of a live, running facter process.  This is a problem
because it makes developing Facter more difficult than it needs to be.
This patch addresses the problem by listing pry as a development
dependency of Facter.  With this patch applied, the following command
may be used to drop into a debugger using the `require 'pry';
binding.pry` statement while running the spec tests.

    bundle exec rspec spec/

This patch also adds the yard and redcarpet development dependencies
which synchronize Facter 1.7 with Puppet master regarding YARD
documentation.
Add on_flush fact resolution DSL method

Without this patch it is difficult to model an expensive system call
inside of an object instance, generate N dynamic facts from the
data contained in the model, then keep all of the resulting fact values
in sync with one another without making N system calls.

This patch addresses the problem by implementing a callback mechanism
when fact values are flushed.  Fact authors may define a so-called
`on_flush` block that will be executed when the fact value is flushed by
Facter.

This block is then useful to invalidate the model data referenced by all
of the N dynamic facts.  The first fact to refresh it's value will then
incur the expense of the system call, but the next N-1 facts do not need
to make the expensive system call as their data has already been
refreshed.

That is to say, flushing the value for all N facts will only incur 1
system call instead of N system calls using the traditional setcode
block.
(#17890) Refactor the facter solaris zone facts

Without this patch the solaris zones fact executes `/usr/sbin/zoneadm
list -cp` on all systems.  This behavior is not confined to SunOS
systems.  This is a problem because this creates noise for the end user.

The root cause of the problem is that the block passed to the Resolution
instance executes before the confinement statement takes effect.  In the
scope of this block is a call to Resolution.exec('/usr/sbin/zoneadm list
-cp').

This patch addresses the problem by moving the behavior for defining the
set of dynamic facts into the Facter::Util::SolarisZones.add_facts class
method.  This method is called only when running on the SunOS kernel.

The add_facts method has the behavior of instantiating an instance of
SolarisZones to model the output of the zoneadm command.  We model this
output because the system command is extremely expensive from a
performance and efficiency point of view.  All of the dynamic facts that
are defined as a result of parsing the zoneadm output retain a reference
to this single model instance.  In the situation where one, many, or all
of the fact values are flushed then the model instance is also flushed.
The first fact to resolve again will refresh the model and all
subsequent resolutions will re-use the data contained in the model.

It is not uncommon to have 10 or more zones defined on a system and
there are 7 dynamic facts generated for each zone.  Without this shared
model instance it is unclear how to avoid executing 10*7 system calls
when all of the dynamic cache values are flushed.