Provide more structural info in `Error::BadResponse`

### Use case

Sometimes, it's useful to detect and handle specific errors on the client side (e.g., `TOO_MANY_SIMULTANEOUS_QUERIES`).
However, now `Error::BadResponse` contains only `String`, forcing users to use `details.contains(code)`.

### Describe the solution you'd like

Replace `Error::BadResponse(String)` with `Error::BadResponse(BadResponseDetails)` where `BadResponseDetails` contains `code` (numeric code), `reason` (string like `TOO_MANY_SIMULTANEOUS_QUERIES`) and `message` (the current `String` argument).

`BadResponse` is also used for HTTP errors, so we need to decide what should be stored in `code` and `reason` in this case. Another way is to divide `BadResponse` into two separate variants.

Start by locating the Error::BadResponse definition and all places where it is constructed for ClickHouse and HTTP errors. Trace the existing response details, then define and document the HTTP representation alongside the requested code, reason, and message fields; done means callers can inspect structured error information without parsing the message.

Written by the indexing model from the issue text.