Have non-waiting requests if we cannot have pipelining

### Is your feature request related to a problem?

Pipelining has real use cases not just benchmarking like has been argued on previous discussion.

For example I have a "DIST" process distributing asynchronous input towards several REST consumers. For example writing data into InfluxDB. It does not get more real than that these days!

When DIST sends a POST(DATA) to one of the consumers, there is no real need to wait for "204" answer. We know it will be OK most of the times. It is more productive to place the data on the socket and move on to the next I/O operation.

With HTTP 1.1 pipelining, DIST would never have to await for responses from consumers, just place data in the pipeline and check periodically for errors. This allows for very efficient use of a **single connection and single asyncio task**.

Without pipelining a similar efficiency can be achieved if just the POST(DATA) request could be started without waiting for server response. DIST could go on working on other things and check the response a bit later when it is likely to be ready without waits.

This is somewhat equivalent to doing `task = loop.create_task(POST(DATA))`, without the overhead of a task.

### Describe the solution you'd like

I would like to have pipelining support on the client. I don't even need full responses to those posts, just error checking.

But with less code changes we could have a `client.request(wait_for_response=False)` returning a future or a coroutine (not a task) to get the response later. The data would be fully sent on return, but no attempt to read the response is made until we wait on that future.

### Describe alternatives you've considered

I have tried writing the requests in plain TCP client, which works for me but is too low level and is missing many features.

I tried implementation with `h11` but it also does not support pipelining and produces funny error "client role cannot handle requests" when trying to send a second requested.

I tried asyncio tasks and callbacks but seem a bit overkill for such a simple use case.

### Related component

Client

### Additional context

_No response_

### Code of Conduct

- [X] I agree to follow the aio-libs Code of Conduct