(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.
(SERVER-150) Put a 'retry' poison pill in the flushed pool

When we replace the old pool with the new pool during a 'flush'
request, we need to have a way to handle the possible race
condition where some code has a reference to the old pool
and tries to borrow an instance from it after it has already
been flushed.  This commit is the first step towards that;
it puts a RetryPoisonPill into the old queue.
DOC-1281 Puppet Server puppet_conf_setting_diffs edit

Edited puppet_conf_setting_diffs.markdown
DOC-1281: Edits to puppet_conf_setting_diffs.

Title change, fixed style on file names (`puppet.conf` -> puppet.conf), and fixed awkward usage error.
(SERVER-150) Check for retry poison pill in borrow macro

This commit updates the jruby-service `with-jruby-puppet` macro
to check for the RetryPoisonPill, and adds corresponding tests.
(SERVER-150) Add basic functionality test for pool flushing
(SERVER-150) Cleanups based on PR feedback
(SERVER-150) Delete unused macro
(SERVER-150) Remove unused `:initialized?` state from service context
(SERVER-204) Subcommands for 'ruby' and 'irb'

Working implementations for ruby and irb to go along with the gem
subcommand. Acceptance tests need to be written, as well as docs.
Merge pull request #313 from cprice404/feature/master/SERVER-150-flush-jruby-instances

(SERVER-150) flush jruby instances
(SERVER-151) Add jruby-pool HTTP Admin endpoint

Add a jruby-pool endpoint to the HTTP Admin API that, when given
a DELETE request, will flush the JRuby pool.
(SERVER-204) Set compatibility version and improve load path order
(SERVER-245) Avoid Puppet 4 being used as a dependency

Without this patch puppet-server allows any version of Puppet >= 3.7.3.
This is a problem because Puppet 4 is on the horizon and will introduce
changes in behavior incompatible with behaviors we depend on.

This patch addresses the problem by specifying that RedHat and Debian style
packages should only use puppet packages >= 3.7.3 and < 4.0.0 to satisfy
the dependencies for puppet-server.
Merge pull request #321 from nwolfe/svr204-ruby-subcommand

(SERVER-204) Subcommands for 'ruby' and 'irb'