(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.
(PUP-1451) Make SSL file permissions a bit more relaxed for public files
(PUP-1120) Make modes of public ssl directories explicit

Previously, the mode of the `certs`, `public_keys`, and
`certificate_requests` directories within the `ssl` directory was
unspecified. This means the actual mode depended on the umask of the
user that started puppet, and caused those directories to be created.

Since the information in these directories is intended to be public,
there is no harm in making the mode explicit 0755. This also matches
what I see when installing puppet from packages.
(PUP-1120) Be explicit about group for ssl directory

Previously, files and directories contained with the `ssl` directory
were inconsistent with respect to their `group`. For example, the
`certs` directory had group `root`, but files within it,
e.g. hostname.pem, had group `service`.

Commit c6846c2b updated the `hostprivkey` and `privatekeydir` settings
so that they are readable by the `service` group. This commit makes
the `service` group explicit for other files & directories in the
`ssl` directory.
(PUP-1120) Remove group write permission for ca settings

Previously, the `service` group was granted write permission for ca
related files, but that is not necessary and likely left over from a
time when puppet did not manage the group correctly for file settings.

This commit removes group write permission for ca settings.
(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.
(PUP-1670) Add validate_cmd parameter to file type

If this parameter is set, then this file will only be written if
the command specified returns 0.

Also adds a validate_replacement parameter to allow specifying some
other string to use for specifying temporary file name instead of the
default of '%'.
(PUP-713) cron: forbid the mixing of special and numeric schedules

The BSD special schedules such as @reboot or @midnight and regular schedules
comprising one or more time fields such as minute or hour are mutually
exclusive. Until now it was valid to specify a special schedule alongside
numeric fields, though.

Add validation logic to the crontype to ensure that a cron resource does not
try to manage these incompatible fields together. It is acceptable to
declare should-values for the respective properties, but only with the
following limitation:

If the 'special' property is declard but not :absent,
any declared numeric schedule field must be :absent.

Raise an ArgumentError type exception that includes a concrete reference
to the special property as well as the title of the offensive numeric
schedule property.
(PUP-713) Add tests for the special property of the cron type
Merge branch 'issue/master/pup-713-disambiguate-cron-schedules'

* issue/master/pup-713-disambiguate-cron-schedules:
  (PUP-713) Add tests for the special property of the cron type
  (PUP-713) cron: forbid the mixing of special and numeric schedules
(PUP-1451) (PUP-1120) Merge branch 'relaxed_permissions'
(PUP-1588) Constrain new msgpack specs to only run with msgpack lib

When msgpack lib is not present (extra group gems not installed), they
will be ignored.
Merge branch 'issue/master/pup-1588-constrain-new-msgpack-tests'

* issue/master/pup-1588-constrain-new-msgpack-tests:
  (PUP-1588) Constrain new msgpack specs to only run with msgpack lib