An `elementsd`-compatible fork of `corepc` for unified RPC client support

## Background

The `rust-bitcoin` ecosystem has converged on [`corepc`](https://github.com/rust-bitcoin/corepc) as a unified library for managing RPC communication with `bitcoind`. It provides versioned, type-safe client bindings for Bitcoin Core's JSON-RPC interface and is actively maintained alongside `rust-bitcoin` itself.

`rust-elements` currently has no equivalent. Downstream projects that need to talk to `elementsd` end up writing their own ad-hoc RPC clients on top of `jsonrpc`. For example, `liquid-functionary` maintains its own [`rpc.rs`](https://github.com/Blockstream/liquid-functionary/blob/master/functionary/src/rpc.rs). This is duplicated effort, and the resulting clients tend to lag behind upstream changes, cover only the methods each project happens to need, and have inconsistent type definitions.

## Proposal

Create an `elementsd`-compatible fork (or sibling crate) of `corepc` that:

1. Keeps all the common parts of `corepc` unchanged. The `elementsd` RPC surface is largely a superset of `bitcoind`'s — the majority of methods are either identical or close enough that `corepc`'s existing types can be reused directly.
2. Overrides the subset of methods that differ. Some Bitcoin Core methods return different or extended data on `elementsd` (e.g. anything involving amounts/assets, blinded outputs, or pegged-in coins). These need Elements-specific response types.
3. Adds the Elements-only methods. Things like `getsidechaininfo`, `getpeginaddress`, `claimpegin`, `rawblindrawtransaction`, `issueasset`, `listissuances`, asset/token RPCs etc. would need to be added.

Structurally, this could be done either as
1. A fork of `corepc`
2. A separate crate that depends on `corepc` and re-exports/extends its types

## Open questions
- Fork vs. extension crate: I am not sure which is easier to maintain?
- Versioning is a little tricky as in `corepc` there are versions of the interface that track the Bitcoin releases and Elements also tracks the Bitcoin releases but also has its own versions.

先比較 corepc 介面與提案中列出的 Elements 專用方法，然後閱讀 liquid-functionary 的 rpc.rs，將其作為重複客戶端工作的範例。決定使用 fork 或擴充 crate 哪一種方式最適合處理共用型別與版本管理。完成條件是：一個相容於 elementsd 的 RPC client 透過可維護的版本管理方式涵蓋所需的差異方法與 Elements-only 方法。

由索引模型根據 Issue 內容生成。