refactor(tx): move AddTransactionProvider to its own crate

[cchudant]

the AddTransactionProvider trait is the interface that abstracts the receiving of transactions in madara.

It is implemented by:

• mc-gateway-client, to forward all the transactions to another gateway. This is used in full-node mode, so that all invoke/declare/deployaccount transactions are forwarded to the starkware (or any other) public gateway.
• mc-mempool. When this implementation is used, the transactions are added to the mempool for block production.

It is used, as an Arc<dyn AddTransactionProvider> by:

• mc-gateway, our implementation of the gateway/feeder gateway
• mc-rpc, our implementation of the rpc specs
• the node operator rpcs for declare v0 txs (very soon it'll be in its own crate, see feat(endpoint): added extra admin rpc endpoint for sensitive rpc calls #386.)
• very soon, in mc-p2p to implement the adding of transactions by p2p pubsub.
• mc-eth (and long-term, its starknet equivalent for L3s) uses it to add L1 transactions into the mempool.

This abstraction is very useful to allow the "frontend" madara services like mc-gateway/mc-rpc to not care about where the transactions actually end up, whether forwarded to other p2p nodes, or forwarded to a gateway, or added to the mempool for block production.
Currently however it resides in mc-rpc, which limits its usefulness. We should put it into its own crate.

We also need to change the error types in that trait to a new error type that would also live in the same crate, because relying on starknet-types-rpc error types is a leaky abstraction that makes sense for mc-rpc but does not suit mc-p2p and mc-gateway. The consumer crates would just have to add a From implementation from that error type to the rpc/p2p/gateway server error type.

[zkjamesfish]

Can I work on this?