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.

We don't have any `Result`s to propagate in this function, so the
`Result` return wrapper is unnecessary.

Must have copied this signature from Civet without thinking:
https://github.com/conduit-rust/rust-civet/blob/ab9c52ca634f65439060c2248295d2ac354aead5/src/lib.rs#L214

Since we don't need to add any additional context or messages here, we
can turn off error context for these variants and shorten error
propagation.

Write doc comments for functions and types, and include a short example.

Reduce a few lines.

Provide a mechanism to get detailed error messages when 500 internal
server errors happen.

We don't want to expose any detailed error information to clients, but
it would be useful for administrators to know the cause of any errors.