(#7911) Allow managing local groups when duplicate names exist in a remote NSS database e.g. LDAP.

Some applications require local accounts and the useradd/groupadd commands currently used by the provider will not create a local account if they already exist remotely.  The libuser commands luseradd/lgroupadd will allow a local name to duplicate a remote name.  So these commands are used to force the local account creation.  The libuser commands parse /etc/libuser.conf to determine which modules to use for creating users.  Files must be the module used to get the desired local account managment.  Because of this, it is necessary for Puppet to ship a libuser.conf file, which will only be used during a Puppet run, to ensure local account managment.  The libuser.conf file used by the luseradd/lgroupadd commands can be overrideen by setting the environment variable LIBUSER_CONF. Which is what Puppet does to make sure its version of the configuration file is used
(#7911) Added support for managing local users.  Also created Puppet::Util::Libuser for better reuse of common code.
(#7911) Removed function def libuser_conf which was made obsolete by Puppet::Util::Libuser
(#7911) Stabalized providers when using libuser commands so it would behave identical to the existing providers

Performed exhaustive analysis of the differences between useradd/groupadd and luseradd/lgroupadd and coded around these differences to ensure that the useradd/groupadd providers behave identically with and without the forcelocal parameter being set.  The only difference being a local account is always created and managed when forcelocal is set to true.  The commands are very similar for the most part so there was not a huge need to diverge from the original code.  In all but one of the cases that did arise the solution was to make a subsequent usermod or groupmod call after the luseradd/lgroupadd command.  Since the usermod/groupmod commands will always act on local accounts first, this achieves the desired effect. The one case where a subsequent call would not suffice was the use of the allowdupe parameter. By default libuser will allow duplicate uid/gid where useradd/groupadd require an explicit -o.  The work around was to manually do a local check for a duplicate if using the libuser library and not intending to allow duplicates.  If a duplicate is found Puppet raises a DuplicateUID or DuplicateGID exception.
(#7911) Fixed failing spec because of invocation of function increase
(#7911) Removed custom exception class for duplicate UID/GID.  Using Puppet::Error now
(#7911) Isolate command environment for libuser commands
(#7911) Moved location of libuser.conf
(#7911) Moved location of libuser.conf
(#7911) Fixed Libuser.getconf, updated unit specs, removed conflicting expiry fix

This commit change the Puppet::Util::Libuser module to look for libuser.conf in its new /etc/puppet/provider/libuser.conf location.  It also updates Puppet::Features::Libuser to only return true if the config file as well as the binaries are found.

Updated the useradd and groupadd specs to expect :execute when called from create to now have 2 parametes.  A command and an options hash.

During my work on this feature I added an exipry getter since the builtin getter didn't retrieve the correct values.  Before this patch was merged another commit came along that also set the proper getter. So I removed mine as it caused a conflict.
(#7911) Cleanup specs, removed unneeded comment
(#7911) Update pw provider specs to account for options hash passed to execute for creates
(#7911) Moved libuser.conf to lib/puppet/util/libuser.conf

Based on internal conversations at Puppet Labs it was recommended that the libuser.conf
file be moved out of Puppet[:confdir]/provider and into the lib/puppet/util directory.

Further discussion will be had and a decision to move this elsewhere may be made, but
for the time being this is where it will stay.
Merge branch 'cprice-puppet-bug/3.0rc/15187-log-fatal-errors-to-console'

* cprice-puppet-bug/3.0rc/15187-log-fatal-errors-to-console:
  (#15187) Ensure that fatal errors are logged to console

closes #900
(#19271) Proper check for which cert to use in ssl error

Don't assume the puppet ca subject name starts with 'puppet ca'
(#18131) Only truncate `puppet describe --list` on sentences

Previously the regexp which attempts to truncate the output
of `puppet describe --list` at the end of a sentence, if it
is within the first 45 characters of the doc string, actually
truncated at the first period/full-stop character. This caused
doc strings which include dots, such as `.k5login`, to be
prematurely truncated.

This commit causes it to instead only truncate at the first
dot-space combination, which is a more reliable indicator of
the end of a sentence.

This also fixes a typo in the spec tests for this code, but
digging further into the code to figure out how to test it
effectively sent me down a rabbit-hole and I gave up.

Paired-With: Michael Hall <mph@puppetlabs.com>
Merge pull request #1481 from ahpook/18131-describe-list

(#18131) Only truncate `puppet describe --list` on sentences
(#593) parsedfile: add support for native file headers

Some managed configurations (notably the vixie cron crontabs) are
automatically prefixed with headers not unlike those generated by
puppet providers themselves. This can lead to "mutual 1up" situations
in which puppet and the third party software will insert header upon
header in their respective output.

This change introduces the a "native header" for a parsed file. Providers
can define a regex object that will be used to identify the part of a parsed
file that comprises such a vendor header.

When writing the content back to disk, puppet will try and insert
its own header underneath the vendor's headers. Additionally, providers
can override a "drop native headers" field in order to have puppet
skip the vendor header alltogether when writing file contents. This allows
"smart" software like vixie cron to manage its header on its own.

The unit tests are based on example code kindly provided by Jeff McCune.
(#593) crontab: drop vixie cron headers when writing crontabs

This makes use of the "native header" of parsed files.

Vixie cron headers should never be written back to disk, because
cron will insert a new header, regardless of what's found in the
temporary input file.

The underlying issue is a cron bug, because vixie headers should
(probably) not appear in `crontab -l` output. This is indeed fixed
in newer versions of cron, so this workaround merely introduces
compatibility with older systems.
Merge branch 'pull-1479'