New app signals proposal to track connections and requests

## Long story short

Right now there is not a set of signals in place to track connections and request for Aiohttp web server. The proposal would implement the following subset of signals, attached to the application.

* `on_connection_created(app, context)` Triggered when a new connection has been created.
* `on_connection_closed(app, context)` Triggered when a connection has been closed.
* `on_request_start(app, context, request)` Triggered when a new request start.
* `on_request_end(app, context, request, response)` Triggered when a requests finishes.

All signals will receive as a parameter the app instance and a context that would help the user to pass information to the next semantic signal. For example, the `context` related with the connection will be instantiated when the `on_connection_created` is called and the value will be passed as a parameter for both connections methods, having the same for the request flavor.

These signals will be only triggered by the root app.

Taking into account that already exists a group of signals for the App and these differ a bit of the proposed ones, lack of context and so on. We could discuss on have a new module called `web_tracing` that will implement the same pattern as the client tracing [1], this might imply some name changing.

My 2cent about my cons with other ways to implement that:

* Middlewares are chained between the root app and nested apps, implement the request signals implicitly as a middleware IMHO is prone error and weak. Better having an ad-hoc set of signals that are never triggered by the nested apps.
* I would prefer to implement these signals out of the app scope, perhaps having them as a new parameter of the `run_app` that implements only these new signals. The problem with this solution is the incompatibility with environments that use the workers strategy to start the application such as `gunicorn`.

[1] https://github.com/aio-libs/aiohttp/blob/master/aiohttp/tracing.py