Add CONTRIBUTING.md
Update CONTRIBUTING.md
Update CHANGELOG for 0.3.11 release
lein-release plugin: preparing 0.3.11 release
lein-release plugin: bumped version from 0.3.11 to 0.3.12-SNAPSHOT for next development cycle
(PE-3673) Standardize on raynes.fs
Merge pull request #140 from nwolfe/pe3673-standardize-fs-dep

(PE-3673) Standardize on raynes.fs
Update CHANGELOG for 0.3.12 release
Merge pull request #141 from nwolfe/0.3.12-z-release

Update CHANGELOG for 0.3.12 release
lein-release plugin: preparing 0.3.12 release
lein-release plugin: bumped version from 0.3.12 to 0.3.13-SNAPSHOT for next development cycle
(PE-3657) Call service stop functions after exception from init/start

Prior to this commit, if a Trapperkeeper service were to allow an
exception thrown during execution of its init or start function to
bubble up to the Trapperkeeper framework, the framework would never call
any stop functions in the services.  Services would not, therefore, have
a chance to clean up any resources that may have been created before the
initial exception was thrown.  If the resources created included worker
threads, for example, those threads could not be cleaned up -- leaving
the JVM process in a *zombie-like* state.

With changes in this commit, stop functions on services would be called
even if an exception had bubbled up to the framework during execution of
a service's init or start function.

There would be a breaking change with this commit.  The `boot-*`
functions (e.g., `boot-with-cli-data`, `boot-services-with-cli-data`,
and `boot-services-with-config`) as well as the `build-app` function on
the `TrapperkeeperApp` instance would now swallow any exceptions
generated which had occurred during an init or start function call in a
service.  The only way to determine if a problem had occurred during
execution of the boot sequence would be to get a handle to the
`ShutdownService` on the app instance and call its `wait-for-shutdown`
function.  If no error had occurred within the init or start function,
this call would block until a shutdown had been requested (e.g., via a
user "manually" killing the process).

Documentation would need to be updated to reflect the nature of these
changes before they could be merged.
(PE-3657) Change type to class in expected-shutdown-reason?

This commit changes the precondition in the expected-shutdown-reason?
test helper to validate that the shutdown reason error is a
java.lang.Class rather than more generically implementing the
java.lang.reflect.Type interface.
(PE-3657) Added get-shutdown-reason and use by bootstrap test utils

This commit includes a new function on the shutdown service,
get-shutdown-reason, which can be used to get the current shutdown
reason (if one exists) without blocking the current thread until the
reason promise is realized.  The internal get-app-shutdown-reason
function provides a way to get at this new function via a handle to the
TrapperkeeperApp.

This commit also includes changes to the bootstrap testutil functions,
which now make use of the current shutdown reason to translate a failure
to bootstrap without encountering an error into an exception thrown up
the stack.  The bootstrap testutil functions also include overloads with
an optional boolean argument which controls whether or not the failure
to bootstrap should result in the TrapperkeeperApp instance being
returned to the caller (true) vs. an exception being thrown (false, and
the default value).

This commit also factors a few common assertions made across several of
the shutdown tests into a helper function.
(PE-3657) README.md and shutdown updates for Trapperkeeper reloaded pattern

This commit fixes up the ability for the "reloaded" pattern to be used
for Trapperkeeper development.  In a prior commit, the build-app
function, used by the "reloaded" pattern examples, would no longer work
if called without a promise argument.  In this commit, build-app can be
called with or without a promise.  If it is called without a promise, a
promise is created and used within the function.  If it is called with a
promise, that promise is passed through to the shutdown service.

This commit also wraps a try/catch around the `init` and `start`
functions in the TrapperkeeperApp implementation with a corresponding
log statement.  This helps for detecting errors when working with the
reloaded pattern in the REPL, where these functions are called directly.
In the prior commit, only functions which wrapped the TrapperkeeperApp
functions would log errors.

This commit also includes some updates to the README.md.  The README.md
documents that `stop` functions may now be called on services even if an
exception were thrown during execution of a service's `init` or `start`
function.  Also, the document includes an updated form of the "reloaded"
pattern REPL example with some code which would help translate a
boot-time shutdown-on-error into an exception from the init or start
call that would be easier to detect while working in the REPL.