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.
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
Adds keep alive support

- Cleans up comments by removing obvious notes
- Moves "close" event to process_client
Fixes readline bugs, uses readavailable
Renames Http to HttpServer
Adds README & REQUIRE