Return headers list field from blockchain.block.headers

[PeterXMR]

Refs #1241 — checks off the blockchain.block.headers "list instead of concatenated hex string" item on the v1.6 protocol checklist.

Summary

Electrum protocol v1.6 changes blockchain.block.headers to return headers as a list instead of a single concatenated hex string.

This PR emits the new headers array alongside the existing hex field, so v1.6 clients consume the list form while older clients keep working. The hex value is now derived from the list (concatenation) so the two cannot drift apart.

⚠️ Design choice — needs your input

I went with additive (both fields) rather than the strict v1.6 reading (drop hex). Reasoning:

• It's backwards-compatible — no existing client breaks
• electrs still advertises PROTOCOL_VERSION = "1.4"; dropping hex while claiming 1.4 would be a spec violation in the other direction
• A future PR that bumps PROTOCOL_VERSION to "1.6" could drop hex as part of that release

Happy to flip to "drop hex" if you'd prefer; it's a 2-line change.

Test plan

• cargo test --lib — 21/21 pass (the function is exercised indirectly through the dispatch path; behavior change is in JSON output shape only)
• cargo clippy --all-targets -- -D warnings — clean
• cargo fmt --check — clean
• Live tested against Bitcoin Core v31.0.0 on regtest with 5 mined blocks:

$ printf '{"id":0,"method":"server.version","params":["test","1.4"]}
{"id":1,"method":"blockchain.block.headers","params":[0,3]}
' | nc -w 3 127.0.0.1 60401
{"id":0,"jsonrpc":"2.0","result":["electrs/0.11.1","1.4"]}
{"id":1,"jsonrpc":"2.0","result":{"count":3,"headers":["0100…02000000","00000020…00000000","00000020…00000000"],"hex":"0100…000000000020…0000","max":2016}}

Each entry in headers is a 80-byte (160-hex-char) block header; hex is their byte-for-byte concatenation (240 bytes / 480 hex chars for a count=3 request).