graceful.Server was made private in 05c2ca7e, but I think the increased
flexibility you get with being able to provide your own TLS options
(etc.) outweighs the API complexity of an additional type.

This bugfix brought to you by `go vet`

I'm not particularly satisfied with the solution here. Maybe the answer
is "more middleware," but I'm not sure.

This fixes up the last few compilation errors caused by the UrlParams =>
URLParams rename.

Wonder how long those have been there.

The "name" parameter was originally a workaround for the fact that function
pointers in Go never compare equal to each other (unless they are both nil).
Unfortunately, this presents a pretty terrible interface to the end programmer,
since they'll probably end up stuttering something like:

    mux.Use("MyMiddleware", MyMiddleware)

Luckily, I found a workaround for doing function pointer equality (it doesn't
even require "unsafe"!), so we can get rid of the name parameter for good.

This change replaces a bit of API surface area (the Sub() method on Muxes) with
a slightly more expressive pattern syntax. I'm mostly doing this because it
seems cleaner: the "*" gets to take on a meaning very similar to what it means
in Sinatra (without growing regexp-like middle-of-a-path globbing, which sounds
terrifying and not particularly useful), and we get to nuke a useless function
from the API.

These were introduced by breaking changes in the following commits:
- aca58b22cf (ValidMethodsKey)
- 386323a6ed (HTTP methods are case sensitive)

I guess I forgot to test it after changing it to an Insert()

I'm totally not making fun of any social networks. Promise.

Who knew! (RFC 2616, 5.1.1)

For sendfile(2) support. I should really DRY up the implementations here...

In order to avoid a dependency on the go.crypto terminal package, let's try to
do our own TTY sniffing. I think in practice this will work surprisingly well,
even if it feels incredibly sketchy.

I've currently written three:
- Request ID generation
- Request logging, with color (!)
- Recovery from panics

Package web will now add a key to the environment when it fails to find a
valid route for the requested method, but when valid routes exist for other
methods.

This allows either the 404 handler or a sufficiently clever middleware layer to
provide support for OPTIONS automatically.

I have no idea if net/http does this for you already, but I may as well do it
myself too...

Add tests for both string and regular expression patterns. Also, reimplement
regexp.Regexp.Prefix() on top of the raw regexp/syntax representation, so we can
get a little more information out of regexps:
- Whether or not the regexp is left-anchored (at the beginning of the string)
- What the prefix of the regular expression is, even for left-anchored
  expressions.

We do this by running the regular expression instructions ourselves, more or
less cargo-culting the original implementation from package regexp/syntax.

Unfortunately it's ~impossible to make this abstraction non-leaky, because the
regexp package doesn't give us information about whether or not it was
constructed using POSIX or Perl syntax, for example, or if the longest-match
setting was applied.

The upshot is that regexps are now probably pretty performant-ish. Maybe. (I
haven't actually benchmarked it).