Use the `REQUEST_URI` param instead of `SCRIPT_NAME` to get the request
path.

Using `SCRIPT_NAME` caused issues with redirects.

If my FastCGI program has the file name `script.fcgi`, and I set up a
redirect from `/script` to `/script.fcgi`, then `path()` should return
`/script` when using that path.

In the above case, because we were using the `SCRIPT_NAME` param,
`path()` would return `/script.fcgi` instead.

This caused routes defined with a `RouteBuilder` to not match correctly.

Now that we're using `REQUEST_URI`, we need to trim the query string and
hash, which are included in the param value, since we only want the URI
path.

This seemed to cause the name to be doubled in the final Apache HTTP
header.

Since it could cause that issue and is not necessary, we can remove it.

The latest version of Conduit, 0.9.0-alpha.3, adds a new `path_mut`
method.

I was getting persistent 500 errors on Apache with mod_fastcgi:

    FastCGI: comm with server "/Applications/MAMP/htdocs/test.fcgi"
    aborted: error parsing headers: malformed header 'HTTP/1.1 200 OK'

Forgot that you need to use a "Status" header for FastCGI to set the
HTTP status code, like:

    Status: 404

This isn't an HTTP server. Apparently knew this at one point for the
DomeKey web site, but completely forgot.

Thanks to Ole (https://stackoverflow.com/users/312098/ole) and
RichieHindle (https://stackoverflow.com/users/21886/richiehindle) on
Stack Overflow for this question and answer that helped me figure it
out:
https://stackoverflow.com/questions/11223166/malformed-header-from-script-bad-header-http-1-1-302-found

Didn't notice this previously as I was using Lighttpd for testing, and
its FastCGI module must be more forgiving.

Since we're only using it in an example binary, it shouldn't be a main
library dependency.