The fast routing diff introduced a regression with how method sets were
calculated for routes that did not match. This fixes that behavior, as
well as making routing considerably more memory-efficient (and therefore
CPU-efficient too) for the case in which many routes share a prefix.

These are based on https://github.com/cypriss/golang-mux-benchmark

Swap out the naive "try all the routes in order" router with a "compile
a trie down to bytecode" router. It's a ton faster, while providing all
the same semantics.

See the documentation at the top of web/fast_router.go for more.

Partially sort the routes on insertion. We're doing this so we can do
more efficient things to routes later.

The sorting rules are a bit subtle since we aren't allowed to rearrange
routes in a way that would cause the semantics to differ from the dumb
linear scan.

I'm about to make changes to the way routes are selected, so we may as
well get good test coverage of that.

This middleware allows you to override a http.Request's RemoteAddr with
a value derived from either the X-Forwarded-For or X-Real-IP headers.

Fixes #12.

Provide a standard middleware to set c.Env. Don't include it in the
default stack, however, since the RequestID middleware will end up
allocating Env anyways.

Fixes #11

They're really verbose. I should probably DRY them up later.

httptest was adding an extra flag, which was sort of ugly. Instead,
reimplement the parts of its functionality we were using. Bonus: due to
specialization, it's now a bit more efficient as well!

This bugfix brought to you by `go vet`

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)

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).

My tests caught some bugs! Amazing!

They say that every programmer builds a web framework at some point. This one is
mine.

The basic idea behind this one is that I wanted a Sinatra for Go, and I couldn't
find one anywhere. Furthermore, net/http is in many ways really close to what I
want out of a Sinatra-in-Go, and many of the frameworks I did find seemed to
reinvent too much, or were incompatible with net/http in weird ways, or used too
much questionable reflection magic. So long story short, I wrote my own.

This implementation is only half-baked, and among other things it's missing a
whole lot of tests.