(#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.