Better documentation on how connection/cursor work

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

I'm using `aiohttp.web` and `aiomysql`. Before reading the source code, I had no idea weather I should:

- Keep a global `cursor` and use it
- Keep a global `connection` and derive a `cursor` for each request
- Keep a global `connection pool` and acquire one for each request

Since the traditional "blocking" model uses the third method, and the simple examples given does not use `connection pool`, I thought method 1 or 2 are also fine.

But after I read the source code, I found that `connection` is essentially a state machine, and `cursor` is a “fake” proxy to it. Reusing the same connection at the same time might cause problems. (Correct me if I'm wrong)

### Describe the solution you'd like

A better documentation is deserved, especially in README.md, that highlights the importance of using `connection pool` in concurrent use case.

### Describe alternatives you've considered

I'm not sure weather mysql supports pipelining in the same connection (like `http pipelining`). If it does, maybe cursors can be implemented that way to support concurrent connection reuse?

### Additional context

_No response_

### Code of Conduct

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