Fixes memory leak with parser's global partials.

The previous methodology with `clean!` was flawed and only
cleaning up the `message_complete_callbacks`. This can be seen
using the following test server:

    using Http
    http = HttpHandler() do req::Request, res::Response
	"$(length(Http.partials)) $(length(Http.message_complete_callbacks))"
    end
    server = Server(http)
    run(server, 8000)

Then:

    > curl http://localhost:8000
    > 1 1
    > curl http://localhost:8000
    > 2 1
    > curl http://localhost:8000
    > 3 1
    > weighttp -n 500 localhost:8000
    > ...
    > curl http://localhost:8000
    > 503 1

It seems that the `clean!` method was not correctly finding
the `parser` pointer key in `partials` – since the key is being
set in C-land by `on_message_begin`.  As such, it seems to make
morei sense to do the cleanup in the `on_message_complete` C callback,
so that the full life-cycle of the global partials can be handled
inside the C callbacks.  Additionally, while the `message_complete_callback`
will remain the same for the duration of a given client connection,
the partial really is only good for a single request.

Of course, this could still potentially leak memory if requests are made
that never finish and end up calling `on_message_begin` but never call
`on_message_complete`. If we could find a way to get the `parser`
key from inside `clean!` it could make a good failsafe, otherwise
we may want to institute some kind of nth request garbage collector
function just to be sure.
Adds RegexNodes and route_params methods
Adds DynamicRoutes: regex, datatype, named & func
Simplifies DynamicRoutes & removes "Converters"

- Radically simplifies logic around dynamic routing.
- Replaces typealiases with named constructors.
- Removes "Converter" routes – no real use case / no simple
  way to inject functions.
Documents DyanmicRoutes & clarifies their syntax
Fixes memory leak with parser's global partials.

The previous methodology with `clean!` was flawed and only
cleaning up the `message_complete_callbacks`. This can be seen
using the following test server:

    using Http
    http = HttpHandler() do req::Request, res::Response
	"$(length(Http.partials)) $(length(Http.message_complete_callbacks))"
    end
    server = Server(http)
    run(server, 8000)

Then:

    > curl http://localhost:8000
    > 1 1
    > curl http://localhost:8000
    > 2 1
    > curl http://localhost:8000
    > 3 1
    > weighttp -n 500 localhost:8000
    > ...
    > curl http://localhost:8000
    > 503 1

It seems that the `clean!` method was not correctly finding
the `parser` pointer key in `partials` – since the key is being
set in C-land by `on_message_begin`.  As such, it seems to make
morei sense to do the cleanup in the `on_message_complete` C callback,
so that the full life-cycle of the global partials can be handled
inside the C callbacks.  Additionally, while the `message_complete_callback`
will remain the same for the duration of a given client connection,
the partial really is only good for a single request.

Of course, this could still potentially leak memory if requests are made
that never finish and end up calling `on_message_begin` but never call
`on_message_complete`. If we could find a way to get the `parser`
key from inside `clean!` it could make a good failsafe, otherwise
we may want to institute some kind of nth request garbage collector
function just to be sure.
Merge branch 'fix-memory-leak'
Merge branch 'master' of github.com:hackerschool/webstack.jl
Changes depreciated wait_accept to new accept
Simplifies formatting of RFC1123 dates