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