Can the `Backend` trait be unsealed?

This issue relates to #11297 which is one of the PRs for integrating the eth-rpc into the parachain nodes (e.g., polkadot-omni-node).

Currently, the eth-rpc communicates with the parachain node through a standard WS connection where subxt is used as the client to facilitate this connection. When the eth-rpc is integrated into the node everything will be running in the same process and therefore there will no longer be need for the eth-rpc to communicate with the node through web-sockets or for an RPC connection to the node at all.

One of the ways in which we're thinking about implementing this is through a custom implementation of the Backend trait. Currently, all of the Backend implementations in the codebase assume that communication with the node happens through an RpcClient and this new Backend we're thinking about implementing would instead call functions in the same compiled binary, bypassing the RPC entirely.

In order to do this, we would need the Backend trait to be un-sealed to allow us to implement our own custom backend.

The questions are:

1. Why is the Backend trait sealed? Is it truly intended that no user of subxt ever implements their own Backend?
2. Could we unseal the trait to implement our own custom Backend?

Start by reading the Backend trait and the existing Backend implementations that use RpcClient. Compare their assumptions with the proposed in-process custom backend, then review the discussion around whether external implementations are supported. Done means reaching a maintainer-backed decision on the trait's sealing and documenting the resulting scope.