Add `Process` logic, for running a Sanford server process

This adds the logic related to running a Sanford server process.
This logic replaces the `Manager` logic and will be used by the
CLI. The `Process` class takes a server and sets up the current
ruby process for it when run. This involves optionally daemonizing
the process, managing a PID file, and starting the server. The
process also traps signals for controlling the process after its
running. The server returns a thread when its started and this is
joined to the main thread, so the process will continue forever
until it receives a signal. It is setup to receive `TERM` which
will stop it gracefully, `INT` which will halt it immediately (not
graceful), and `USR2` which will perform a hot restart. To perform
the hot restart, the process runs a `Kernel.exec` which replaces
the current process with the new process defined by the args passed
to the `exec`. The TCP server is only paused when this happens, so
its still accepting connections, just not processing them.

This also requires that the server have a name since the `Process`
logic uses it to name the system process and also in logging. This
is handled in the configuration validation, which is called when
the server is initialized.

This fixes some bad practices in the old `Manager` logic related
to the trapping of signals. The server commands for `stop`, `halt`
and `pause` do not perform any of the logic for actually stopping
the server. They proxy DatTCP which simply writes the command to
a `IO.pipe` and then exits. The original thread running the server
then gets this and handles shutting down the server as needed.
This is a better practice than doing all the processing in the
actual signal traps. I ran into problems with the old logic that
are not present with this implementation.
Merge pull request #120 from redding/jcr-process

Add `Process` logic, for running a Sanford server process
Remove `Runner.run` and `ServiceHandler.run`

This removes the `Runner.run` and the `ServiceHandler.run` class
methods. These were a neat feature but haven't really worked out
or been used. Since these haven't been used, this removes them so
they no longer have to be maintained. With planned changes to the
`Runner.new` args, this avoids having to update both of these
methods to using the new args.
Merge pull request #122 from redding/jcr-remove-runner-handler-class-methods

Remove `Runner.run` and `ServiceHandler.run`
Add `ProcessSignal` for sending signals to a Sanford process

This adds logic for sending signals to a Sanford process. This
will be used by the CLI to stop, halt or restart a Sanford
process. It will try and find an existing PID file for the process
and send the signal to the PID stored in it. This replaces logic
that currently exists in the `Manager`.
Merge pull request #121 from redding/jcr-process-signal

Add `ProcessSignal` for sending signals to a Sanford process
Add `ConfigFile` for evaluating Sanford config files

This adds the logic for evaluating Sanford config files. This will
be used to "choose" which server you want to run via the Sanford
CLI. These files work in a similar manner to Rack's rackup files.
The file expects `run` to be called with a Sanford server. The
CLI will then use the server to either start a process or send
a signal to an existing process.

This also renames the `Server` in `test/support` from `TestServer`
to `AppServer`. This is to avoid collisions with the usage of
`TestServer` in unit tests that rely on a server. I don't want to
accidentally couple these unit tests to this server or alter the
server so that the system server tests start breaking in strange
ways.
Rework `CLI` to use `ConfigFile, `Process` and `ProcessSignal`

This reworks the `CLI` to use all the new logic. It now expects
a config file path and builds a `ConfigFile` to evaluate it. The
server from the `ConfigFile` is then either passed to a `Process`
or `ProcessSignal` depending on the command. Sanford supports the
same commands it did previously: run, start, stop and restart.
This makes all of Sanford's old logic no longer needed and it
will be removed in a future commit.
Rename `Server::ConfigData` to `ServerData`

This moves the `ConfigData` out of the `Server` file and renames
it `ServerData`. This is setup for passing the `ServerData` down
to the route, runner and having its data accessible in service
handlers. Ultimately, its needed throughout Sanfords stack and it
felt wrong to require the server everywhere it was needed. This
moves it to its own file but keeps it associated with the server
by renaming it. This has become very similar to how Deas currently
handles the sinatra object. It is passed through to the runner
and is accessible to the service handler.
`TestRunner`, dependency inject attributes on service handler

This adds dependency injecting attributes on service handlers
with the `TestRunner`. This allows passing more than just params
when using the `test_runner` test helper. The `TestRunner` now
takes a hash of args and it will pull out keys for params, logger
and a request. Any other keys in the hash will be used to try and
write their values to the service handler it builds. This allows
dependency injecting values when a handler is built.

This also changes `Runner` to no longer have an `init` and `init!`
methods. These were originally done when `Runner` was a mixin that
could be used and configured on servers. This is no longer the case
and they were only used by the test runner so there's really no
need to keep these methods.

This also moves the serializing of a response. It is now done
whenever the test runner builds a response, either from initing
or running the service handler, not just when its run. This makes
sure that when a handler halts in its `init!` or a callback, we
also try to serialize these responses to ensure they don't throw
any errors.

Finally, this adds unit tests for the test runner. Previously it
was only tested implicitly via the service handler.
Pass `ServerData` to route, runner and service handler

This adds passing a server's `ServerData` to a route when running
it. The route then uses the `ServerData` to build a runner. This
changes `Runner` to require a server data and forces the
`TestRunner` to build one and `super` it to conform to this. This
makes the `ServerData` available to the runners and also service
handlers, which allows removing usage of `Sanford.config`.
Previously, runners used `Sanford.config` to default their logger
and service handlers used it to default their template source.
Since `Sanford.config` is going away, they needed to get this
data through their server's configuration. The logger was already
being passed in (from the server data) so this just changes it
to default to a `NullLogger` if one isn't provided. Runners now
knows their template source and default it to a null template
source in the case one isn't provided. When rendering, a
service handler will default its template source to its runners
template source. This removes the usage of `Sanford.config` so
it can be removed in a separate commit.

This also makes a small change to runners to demeter their
request params. This is called by the service handlers `params`
method instead of it calling the request and then calling `params`
on that.