(#18718) Load logger classes eagerly

The old behavior of autoloading the logger classes, as well as a few
other classes, isn't needed because those classes are always around and
there is no harm in loading them. By loading them eagerly things become
a bit more predictable.
(#18718) Create logger to handle fallback

Sometimes a logger has been configured, but is not suitable for being
used. An example of this is when the puppet logger has been configured,
but hiera is not being used inside puppet. This adds a FallbackLogger
that will choose among the provided loggers for one that is suitable.

The FallbackLogger assumes a new method on loggers called #suitable?.
This method, if present, returns true if the logger will work and false
if it won't work. If there is no #suitable? method, then the
FallbackLogger assumes that the logger is suitable, which is for
backwards compatiblity with existing loggers.
(#18718) Enable console fallback when logger not suitable

Given the current configuration system for hiera, there is only ever one
logger that is configured. If that logger ends up not being suitable,
then we will always fall back to console logging.
(#18718) Implement suitablity check for puppet logger

The puppet logger is only able to be used if Puppet is available. This
is done with a simple check for the existance of the Puppet constant.
Merge pull request #117 from zaphod42/issue/1.x/18718-hiera-puppet-logger-cli

(#18718) Fallback to Console if Puppet not available