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.