Refactor transport Module to ethrpc

[nlordell]

In refactoring for configurable max batch size, I wanted to move all Web3 related code into a parent module. transport felt like the right place, but with the wrong name.

This PR just renames the transport module to ethrpc and moves the Web3* types to this new module. I felt like this name was slightly more appropriate because:

• transport is very generic and web3-crate-specific terminology
• ethrpc more accurately represents what the module is for (i.e. all Ethereum RPC related code: the Web3 "connection" instance, underlying Transport implementations, Ethereum RPC extensions, etc.)

Test Plan

CI. No logic changes, just moved code.

[sistemd]

👍

[sistemd]

Although I do think BatchingTransport might be a slightly better name. BatchTransport is a name already used by the web3 crate to mean something different (a transport allowing batches), but I don't think that's a problem.

[nlordell]

I called it Buffered instead of Batched just because it does primarily request buffering (and, as a side-effect, automatically groups buffered requests into batches).

For example:

Configuration {
    max_batch_size: 1,
    max_concurrent_requests: 5,
    ..Default::default()
}

Will just buffer requests and make sure only 5 at a time are sent to the node, but never make any batched RPC requests.

Don't know if this makes sense. Also fine with changing it, I'm not too attached to the name (and "buffered" is quite generic lacking specificity).