(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.
Merge pull request #2333 from zaphod42/doc/master/update-developer-intro-docs

(doc) Split up README_DEVELOPER