(maint) docs for admin API + /environment-cache

* Add docs on the new /environment-cache endpoint.

* Update the config doc with more detail about configuring the admin
  API.

* Minor formatting / wording fixes in the /certificate_status section.
DOC-1281: edits for Puppet Server external_ca_config
DO-1281: Puppet Server docs, external_SSL_termination

Edit and reorg of external_SSL_termination document for Puppet Server.
minor wording / capitalization fixes
DOC-1281: edits to external_ca_configuration and external_SSL_termination pages

Edits and adding a note about X-Client-Cert.
(MAINT) Fix typo, it's ruby-load-path, not paths

Setting ruby-load-paths instead of ruby-load-path results in:
Caused by: java.lang.Exception: JRuby service missing config value 'ruby-load-path'
Merge pull request #307 from jasperla/load-path

(MAINT) Fix typo, it's ruby-load-path, not paths
(maint) Add in support for the packaging repo

Since puppet-server is built with ezbake, this addition is not
necessary. However, we do want to be able to create release tickets for
the puppet-server project when the time comes for a release. It does
seem a little silly to add in support for the entire packaging repo just
to create release tickets, but ultimately that funcionality will be good
to have easy access to.

Note, the yaml files included in this pull request are the minimum
viable to generat the release tickets. A lot of the other tasks and
automation available through the packaging repo will not work because of
what is left out. Again, if those tasks are needed, they should be run
with EZBake.

In order to create tickets, in the puppet server project, run the
following:

`rake package:implode package:bootstrap`
`rake pl:tickets BUILDER=melissa DEVELOPER=$you WRITER=jean
RELEASE=1.0.0 DATE=2014-12-15 JIRA_USER=$you PROJECT=SERVER`

The DEVELOPER corresponds to the persion who is going to coordinate the
release. The BUILDER is the Release Engineer working on the release, and
the JIRA_USER is the person who is creating the tickets. It is important
that the names all correspond to actual jira usernames.

More documentation is available at
https://github.com/puppetlabs/packaging/blob/master/tasks/tickets.rake#L408
Merge pull request #305 from melissaanne/master

(maint) Add in support for the packaging repo
(MAINT) Update TK and Kitchensink dependencies
(SERVER-160) add known issue to documentation

Copy the known issue about /tmp mounted as 'noexec' from the PE documentation.
(MAINT) Added jira-ruby to Gemfile
(SERVER-160) update docs on known issues
(SERVER-160) fix typo
(SERVER-150) Use clojure agent to initialize jruby pool

This commit gets rid of our use of a raw `future` when priming the
JRuby pool.  Instead, we use a clojure agent.  This has the
following benefits:

* Will make it easier to re-use the pool initialization logic
* When we expose a way to request for the pool to be flushed,
  will make it possible to prevent multiple pool initializations to
  occur simultaneously
* Gives us more robust options around error handling, since we
  could now call `agent-error` on the agent instance to make
  sure that nothing has gone wrong
* Provides some scaffolding that we can re-use in order to have
  another agent handle the flushing of an existing pool
(SERVER-150) Refactor `prime-pool!` to be more re-usable

The previous implementation of `prime-pool!` required a
`PoolContext` object as input.  This meant that the
function could not be used to prime a pool that was not
yet part of a `PoolContext`.

This commit refactors the function so that it operates on
a `PoolStateContainer` instead; this will allow us to
initialize a pool before putting it into the `PoolContext`.

Conflicts:
	src/clj/puppetlabs/services/jruby/jruby_puppet_core.clj
	src/clj/puppetlabs/services/jruby/jruby_puppet_service.clj
(SERVER-150) Refactor `borrow`, et. al, to use pool directly

Prior to this commit, the `borrow-instance` and related functions
in jruby-core required you to pass a `PoolContext` object in
as input.  This prevented us from using these functions on a pool
that has not yet been added to the context.  This commit modifies
the signatures to accept the pool object directly, rather than
the `PoolContext`.

Conflicts:
	src/clj/puppetlabs/services/jruby/jruby_puppet_service.clj
(SERVER-150) Refactor `return` to not require pool

Prior to this commit, the various `return` functions that would
allow a caller to return a JRuby instance to a pool required
that you also pass in a reference to the pool that the instance
should be returned to.  This allowed the possibility of returning
an instance to a pool that it did not actually originate from.

This commit refactors the creation/borrow/return logic such that
an instance maintains a reference to the pool that it was
borrowed from, and the `return` functions use that reference
when returning the instances to a pool.  This guarantees that
instances will always be returned to the correct pool that they
were originally borrowed from.
(SERVER-150) Convert JRubyPuppetInstance to defrecord

This commit changes the JRubyPuppetInstance schema from a normal,
map-based schema to a schematized `defrecord`.  This may result
in a very minor performance improvement, but the main motivation
is to provide better compatibility with REPL-based developer
utility code.  Since we added a reference to the JRuby pool to
the schema for JRubyPuppetInstance, attempting to print the
objects results in a stack overflow, because Clojure's implementation
of `toString` for maps will recurse into these references to the
pools and attempt to print all of the instances again.

Moving to `defrecord` would allow us to override `toString` if we
wished to do so, but the default implementation of `toString` for
a record does not have the same problem with recursion that the
map objects do, so simply converting to a record solves the issue
and allows all of the utility code to be used in the REPL again.
(SERVER-150) Add service function for flushing JRuby pool

This commit adds a new service function to the JRubyPuppet service.
The new function can be used to request a flush of the JRuby pool.

The function is implemented by creating a new (offline) JRuby pool
and starting to populate it; as soon as the first instance is ready,
we can swap it into the service and remove the old pool, and then
continue initializing the remaining instances and cleaning up the
old pool in parallel.  It uses clojure agents to coordinate the
creation of the new pool and the cleanup of the old pool.