(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.
(PE-3657) Addressed some PR feedback

This commit includes the following changes:

* Removed validation of the shutdown reason promise since it relied upon
  Clojure implementation details that may not hold true in the future.

* Pushed try/catch for logging lifecycle function errors down into
  `run-lifecycle-fn` to avoid repeating the same code in the calling
  layer.

* Moved `translate-app-shutdown-error-into-throwable` from testutils
  to app->shutdown-error-throwable-or-app in the production internal
  namespace.  Follows function naming convention for conversion and
  available for later application reuse.
(PE-3657) Added check-for-errors! to App and reworked reloaded example

This commit adds a `check-for-errors!` function to the TrapperkeeperApp.
The function is used by the reloaded repl example in the README.md to
propagate any errors captured during the init and/or start phase of the
bootstrap process up as a java.lang.Throwable.
(PE-3657) Removed some unused / unecessary imports and requires

This commit removes a few unused / unnecessary imports and requires
which had been present in the previous commit.
(PE-3657) Addressed more PR feedback

This commit includes miscellaneous changes based on PR feedback:

* Cleanup in the reloaded repl example code in the README.md.
  `alter-var-root` -> `check-for-errors!` threaded call replaced with
  nested call.

* Removed overload of `build-app*` which allowed the shutdown promise to
  be omitted from the call, with a default promise being generated
  inside of the function.  Changed `build-app` to create and pass in its
  own promise into `build-app*` to compensate for the removed overload.

* Changed name of `app->shutdown-error-throwable-or-app` to
 `throw-app-error-if-exists!`.

* Removed overloads of `bootstrap-*` functions with support for
  boolean that controlled whether the functions would return an app or
  throw a `Throwable` based on the existence of a shutdown error.
  Functions now always throw a `Throwable` on presence of a shutdown
  error.  Tests needing the "return app on error" behavior were
  updated to call `boot-services-with-config` in Trapperkeeper core
  to achieve the "return app on error" behavior.

* Some unused references to the `:ShutdownService` were removed from
  tests.
(PE-3657) Updated reloaded example in README.md around `alter-var-root`

This commit splits the `alter-var-root` and `check-for-errors!` calls
from `init` and `start` in the README.md's reloaded repl example into
independent forms rather than having them be chained together.
Merge pull request #142 from camlow325/maint/master/PE-3657-abort-process-on-boot-exception

(PE-3657) Call service stop functions after exception from init/start