Switch to PHP's built-in server.

While PHP's built-in web server is not really meant for production use, neither
is RackLegacy. But it should offer a performance boost because it keeps the
PHP process running between requests. This means:

* No PHP startup time.
* PHP can cache compiled code.
* PHP can cache database connections between requests.

In addition to a probable performance boost is massively simplifies the code.
We use two new gems to make the interaction simple and PHP ensures we are
responding just as PHP normally would.

This change might break code using Rack::Legacy for the following reasons.

* If you are specifying the php binary you will need to switch from the
  php-cgi binary to the php CLI binary.
* I am no longer processing directory requests. I think that job is better
  reserved for a new middleware (my next task). The current method was
  inflexible because it didn't support index.html or index.cgi. Even if we
  added that support there would not be a way to specify your preference.
* If you are using the default port we picked you will need further config.
* There are some areas where we were actually not mimicing PHP correctly.
  For example we were processing HTTP status's incorrectly and we were
  returning a 500 error when exiting with a non-zero status (like CGI).
  Now that PHP is doing the work these deviations from how PHP worked have
  been removed.
Switch CGI implementation to use ChildProcess for the following reasons:

* We are already using it for the PHP process management
* The API of ChildProcess is simpler than using popen, etc manually.
* It offer cross platform support.
* It offers more efficient mechanisms like POSIX_SPAWN which can even
  be enabled via the CHILDPROCES_POSIX_SPAWN environment variable.