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