Moving into the 2.x rule-based proxy architecture.

The 1.x RProxy architecture was a simple one. Each server had one or more
downstreams which were global; Meaning all "rewrite" section would use
connections from all of the configured downstreams. This approach was effective,
but not optimal for a more dynamic setting.

The goal of the 2.x series was to allow a user make a downstream an autonomous
entity. Instead of rewrites, we have rules. Each of these rules can now be
configured to use specific downstreams, each with their own method of
load-balancing and settings.

Downstream configuration within a server section remain (in most cases) the same
as 1.x, the one major difference is that they are named. The name of the
downstream is how they are referenced inside a rule.

Take the following example:

downstream one {
addr        = 127.0.0.1
port        = 8080
connections = 5
}

downstream two {
addr        = 127.0.0.1
port        = 8081
connections = 2
}

downstream three {
addr        = 127.0.0.1
port        = 8082
connections = 10
}

if-uri-match "/foo" {
downstreams = { one, two }
lb-method   = roundrobin
}

if-uri-match "/bar" {
downstreams = { three }
}

if-uri-match "/baz" {
downstreams = { one, two, three }
lb-method   = rtt
}

For each downstream, the configured number of connections are established and
treated as a pool. Each rule defined will use the names of the downstream pools
to use connections from. In the configuration above:

5  connections are made to 127.0.0.1:8080
2  connections are made to 127.0.0.1:8081
10 connections are made to 127.0.0.1:8082

These connections are global to a single server section.

If the upstream URI is "/foo", requests are serviced by using one of the
connections in either the "one" or "two" downstream pool using a round-robin
load balance method, e.g., first request goes to "one", second to "two", third
to "one", etc, etc.

If the upstream URI is "/bar", only connections from the "three" connection pool
will be used to service the request.

In order to achieve this new arch, a fairly large refactoring of the code was
needed. And in this process it was decided to completely deprecate 1.x
compatibility; this made sense to ensure developer sanity stays intact.

1.x will go into a purely maintenance mode, new features will not be accepted
and should be applied to 2.x. On the other hand, bugs will be dealt with on a
case-by-case basis.

All that said, this is the initial commit.

Things that are currently not working or are considered buggy:

o Logging doesn't work right now; I am working on making this much more flexible
  than the 1.x configuration.

o We now require libevhtp v0.4.14 or greater to satisfy the new wildcard
  matching features.

o Added per-rule upstream read/write timeout config.

  You can override the server { [read|write]-timeout } configuration for upstream
  client connections on a per-rule basis now by adding "upstream-read-timeout" or
  "upstream-write-timeout" (value being { sec, msec }) to a rule section.

  Example:

    server {
       # set upstream socket read timeout to 60 seconds
       read-timeout = { 60, 0 }

       if-uri-match "/blah" {
            # set upstream socket read timeout to 3 seconds if this rule matched
            upstream-read-timeout = { 3, 0 }
       }

       if-uri-match "/bleh" {
            # no read-timeout
            upstream-read-timeout = { 0, 0 }
       }
    }