Dropping .elapsed in favor of event hooks.

[tomchristie]

Currently we have a response.elapsed API built-in, which uses some slightly odd mechanics under-the-hood.
It's also not especially useful as it only monitors the metric of "time between request send and response close".

Since we're focused on simplicity of the stack throughout, I'm proposing here that we consider dropping this.
In it's place I'm suggesting that we adapt the request hooks slightly to include a 'close' event, and allow developers to add request timing themselves if required.

We would...

• Drop the internal BoundSyncStream/BoundAsyncStream.
• Drop the internal Timer.
• Drop the Request.elapsed public API.

And...

• Add a 'close' event hook.
• Add a documentation example showing how to add timing to a request.
• Include event_hooks as a request extension, in order to implement firing a 'close' event from the response.

We'd include a documentation example that would be something like this...

# Adding `response.elapsed` timing information...

def on_request(request):
    request.started = datetime.datetime.now()

def on_close(response):
    response.elapsed = datetime.datetime.now() - response.request.started

client = httpx.Client(event_hooks={"request": on_request, "close": on_close})

Using this approach developers can time either or both of "time until response returned" (using the 'response' event hook) / "time until response body read to completion" (using the 'close' event hook).

We probably also end up with a side-effect here of supporting per-request event hooks. (Eg. see #2991)

There's also scope for us to consider how this could tie in with the 'trace' extension for finer grained metrics.

[T-256]

Some contexts of BoundSyncStream issue: #2777