refactor!: normalize responses into a shared HttpResponse

[MaxFangX]

#97 plans to abstract the HTTP client away. This PR makes progress towards
that goal by centralizing response handling in one client-agnostic type, so
that only the code producing it touches the underlying HTTP client.

Additional motivation: To address the immediate performance and reliability
problems caused by the switch to bitreq (outlined in rust-bitcoin/corepc#587),
Lexe needs to switch back to using reqwest as our underlying HTTP client.
After #241, it looks like a patch to add reqwest back in under an opt-in
feature flag unlikely to be upstreamed, so Lexe will need to maintain a fork of
rust-esplora-client. This refactor has minimal logic changes but makes the
maintenance of our fork a bit easier for us.

Concretely, responses are normalized into a private HttpResponse (status +
fully-read body) as soon as they leave the HTTP client. Retry loops, status
checking, and all endpoint methods in both clients now operate on this shared
type, so swapping the HTTP client (whether for our reqwest patch or for #97)
only touches the few functions that produce an HttpResponse.

The refactor also DRYs up the status checking and error construction previously
duplicated across both async and blocking clients, and deletes the
bitreq::Response status predicates, four of which were dead code.
Net -34 lines.

Breaking changes:

• BlockingClient::post_request is now private (it returned a raw
  bitreq::Response).
• JSON and UTF-8 decode errors are now reported via Error::SerdeJson and a
  new Error::InvalidUtf8 variant rather than wrapped bitreq errors.