(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.