[Feature Request] RPC Support for Full Node access without trust assumptions

## RPC endpoints for light clients

A light client protocol can verify the correctness of any data it receives about the Aptos block chain without making trust assumptions on the provider of that data (a PFN, a commercial RPC provider, etc), as soon as it performs validator signature verification, and can justify the signers of the data through a series of epoch changes. One use case for deploying this light client protocol is secure bridges, another is trustless wallets.

At Lurk Lab, we've been working on a [ZK-light client](https://wormhole.foundation/blog/wormhole-foundation-awards-contributor-grant-to-lurk-lab-to-bring-trustless-transfers-to-wormhole-with-zk-proofs), and we've faced challenges in accessing input data. These challenges would be removed by opening RPC endpoints on the full node that allow access to that (pre-existing) data.

In the light client protocol, the core data we work with is Merkle inclusion proofs (for value inclusion at a particular block height), and `LedgerInfoWithSignatures` (both for certifying the SMT root, and to check the `EpochChange`). More specifically:

- a fresh `SparseMerkleProof`, and the related `TransactionProof` and `AccountProof`,
- the `LedgerInfoWithSignatures` that are either related to an `AccountProof`, or conveying an`EpochChangeProof`.

We would like to access this data without needing to modify the PFN code, and the RPC interface seems the natural place for that.

> [!IMPORTANT]
> This issue does not contain anything specific to ZK: *any* verifying bridge (including e.g. optimistic bridges) needs to get access to the same data, and would face the same challenges.

> [!NOTE]
> We've previously discussed how we process this data in #10747, #11824 and #13440. The present issue can be seen as an extension of #7401.

## In detail

To grab the data we need for this, we've managed to hack a full node into dumping the `LedgerInfoWithSignatures` and the MerkleProofs we needed. You can find it at https://github.com/lurk-lab/aptos-core/tree/release/aptos-node-v1.14.0-patched today.

The core new endpoints are about :
1. retrieving Merkle inclusion proofs at a recent block height, (`get_account_proof`)
2. retrieving the block header for the SMT root finishing (1.), (bundled in the above)
3. retrieving the block headers for the Epoch change proof. (`get_epoch_change_proof`)

The functions for doing most of this were present in the full node and were fine to use (thanks!). However, it would have been a lot easier to do all of this if those (mostly pre-existing) functions had been exposed as RPC endpoints by the full node itself. Then we'd just run an off-the-shelf full node, and generate the inputs we need.

> [!TIP]
> In making access to core data structures easier from the RPC interface of the full node, Aptos would join existing chains (e.g. Ethereum through [EIP-1186](https://eips.ethereum.org/EIPS/eip-1186)), and:
> - facilitate verification not only for folks that don't want to run a full node (e.g. light clients) but also offer convenience for those who do,
> - incentivize RPC relayers (e.g. Alchemy, Infura) to provide signature data in ways that allow using those Web2 services w/o a trust assumption.
>
> For instance, despite EIP-1186 being *nominally* stagnant, it is widely implemented and deployed by those commercial RPC providers ([alchemy](https://docs.alchemy.com/reference/eth-getproof), [infura](https://docs.infura.io/api/networks/ethereum/json-rpc-methods/eth_getproof) ...).