source function library *before* client sysconfig overrides

My client's environment mandates strict umask settings:
  - 027 for init scripts
  - 077 for normal users
This causes problems when using exec resources or any add-on functions
that exec external scripts/programs.

The fix is relatively simple - run umask in /etc/sysconfig/puppet
and set a more lenient umask for puppet.
However, the /etc/sysconfig/puppet is sourced before the init
function library so any umask changes made in the former are
overridden by any in the latter.

Looking in other init scripts (including the puppetmaster init
script), it is usual for the function library to be sourced at the
start of the init script, ie. before the sysconfig override.

This change simply moves the lines that source the init function
library to the start of the init script.
(PUP-1174) enable the purging of authorized ssh keys

Purging authorized ssh keys is difficult because there is no way know
where key files may be located. Users commented that for most it should
be sufficient to clean the keys from users that puppet manages.
John Bollinger suggested a design that's based on a new parameter to the
user type. There are two ways to use it:

user { "name": purge_ssh_keys => true }

to make puppet purge from the default ~/.ssh/authorized_keys file, or

user { "name": purge_ssh_keys => [ "/etc/keyfiles/name" ] }

to specify one or more files in non-standard locations.

The implementation is similar to the file type's purging code. The user
type now has an eval_trace method that searches the specified files for keys
and adds any unmanaged keys to the catalog with ensure => absent.
(PUP-1174) amend resources type documentation

Add a reference to the new purging feature to the documentation of the
resources type description.
(PUP-1174) add tests for the purge_ssh_keys parameter of the user type
Clarified `pattern` parameter for Service type (DOCUMENT-1)
(DOCUMENT-22) Clarify matching of crontab entries

This updates the documentation to be consistent with behavior introduced in
commit da9162c.
Clarified the use of slashes around RegEx for `pattern` attribute
Fix PUP-1568 - no success variable anymore

In the refactoring within 000b8fef the success variables was
removed. So the error message shouldn't anymore use it.
Fix broken spec & wording of error message.

While working on 658f1237c1596a6f735b7b707130fc0897a1a113 I stumbled
accross another messages that would say 'with error code false', which
doesn't make a lot of sense. Also the plain 'expect raise_error' was
masking another problem with tests. One should always only look for the
exact expected error and not just general for any kind of error.
(PUP-1066) Add the ability to delete files.
Add a .destory and .destroy? in order to flag files for deletion.
We also sneak in a .entries reader in order to let us read the
entries directly.

This should fix PUP-1066 and #12687.
(maint) Switch from -fd to -fp for specs to reduce disk space usage
(doc) Point to the local docs

Rather than pointing to some remote form of the docs that are part of
the repo, we should point to the local files. This makes the docs more
self contained and better versioned together.
(doc) Create a quickstart guide to get people going

The README_DEVELOPER document has become too long for many new
contributors to quickly get going. The setup instructions were hidding
far down inside the file and provided to many caveats for a quick setup.
This splits out that information, streamlines it to take an opinionated
stance on how to setup a development environment, and start the process
of creating a set of documents tightly tied to the puppet codebase.

This new docs area should be used for documents about developing on the
puppet codebase, documentation of internal architecture, and other
developer and development focussed documents.

This also moves the acceptance test documents to this new location.
(doc) Extract sections of README_DEVELOPER

This pulls the various parts of README_DEVELOPER into individual files
and links to them from the docs/index.md. This should give us a place to
better organize these internal docs.
(doc) Remove remaining developer docs

The rest of the items in the developer docs (those not moved to the docs
directory) are of limited value. Instead of keeping these docs around
and having them fall out of date, they are just going to go away.
(doc) Explain some basics for profiling puppet

This doesn't make it all clear, but it should give a good starting point
for how you might go about profiling puppet.
(doc) Stop using non-words

"Contributioning", although very cool sounding, is not actually a word.
It is "Contributing" to the rest of the world.
(doc) Clarify use of --profile

There are a few different ways that you can use profile. This splits up
the explanation into the 3 different cases in which it can be enabled
and a bit of explanation about when you might use each one.
(doc) Point readers to how to run acceptance tests
(doc) Update rspec examples to show desired style

There are a couple stylistic points about rspec that we need to follow:

  * be explicit
  * say what it does

"Be explicity" means that we use `before :each` instead of `before`.
This lowers the amount of mental energy that a reader needs to use to
understand how things will fit together.

"Say what it does" means that the examples read as declarations of what
the system under test *does*. A writer must avoid wish-washy words such
as "should" or "could" or "may". Instead state exactly what the system
does in that situation.