Build DatTCP server when initializing a Sanford server

This updates the new server logic to build a DatTCP server. This
allows the Sanford server to actually listen and serve connections
made to it. This adds the same socket handling behavior as the
old server logic, only it builds and runs a new worker. This also
adds all the same configuration and socket handling from the old
server logic. The TCP server will have the `TCP_NODELAY` option
set on it and in a linux environment, the client socket will
be "corked" as before. This finishes the main work on the
new `Server` logic and it can now replace the old server logic
in the test suite.

This also fixes a few mistakes made in previous commits. The
configuration now adds its routes and error procs to its hash.
Otherwise the config data won't ever get them. I also updated the
`router` DSL method to take a block so services could be added
to the router via the server definition.
Merge pull request #117 from redding/jcr-server-build-dat-tcp

Build DatTCP server when initializing a Sanford server
Switch to testing the new `Server`, remove the old `Server`

This switches the test suite over to testing the new `Server`
and removes `ServerOld`, `WorkerOld` and all the testing
that went with them. This reworks the recipient handling system
tests as server system tests and runs them against the new server
logic. This ensures that the new server should handle requests
like the old one did.

This puts in a hack to get the new server logic working with the
existing CLI/manager logic. It builds an anonymous service class,
using the host configuration for the servers configuration. This
works, but is not going to be the way this is handled going
forward. This is temporary so the bench scripts can be run and
so we don't have Sanford in a broken state.

Finally, I found a "bug" that I believe was introduced with the
latest DatTCP (v0.5). I found that after hot restarting, I would
get a random `SignalException: SIGALRM` that would cause the
process to exit. I found this is a "bug" with the manager
implementation of restarting. The problem is the manager runs all
the restart logic in the trap for the restart signal, which is a
bad practice. Because DatTCP pauses so quickly, the original
thread for the server doesn't get to exit appropriately before
we run `exec` and replace the process. This seemed to cause the
`SIGALRM`. I found that if I just turned on DatTCP logging, which
should slightly slow it down when being paused, the issue would
go away. To handle this, I patched the restart logic to join the
server thread and make sure it exits before calling `exec`. This
cleared up the problem and confirmed my suspicions that the
thread was not properly exiting.