feat: implement anvil_metadata/anvil_nodeInfo API endpoints

[itegulov]

We need to decide on our metadata/node info format, likely something close to anvil + some potential ZKsync-specific stuff.

#[rpc(name = "anvil_metadata")]
fn metadata(&self) -> RpcResult<Metadata>;

#[rpc(name = "anvil_nodeInfo")]
fn node_info(&self) -> RpcResult<NodeInfo>;

[itegulov]

anvil_metadata

Anvil inherited anvil_metadata as an alias to hardhat_metadata and they kept compatibility with their format:

pub struct Metadata {
    /// client version
    pub client_version: String,
    /// Chain id of the node.
    pub chain_id: ChainId,
    /// Unique instance id
    pub instance_id: B256,
    /// Latest block number
    pub latest_block_number: u64,
    /// Latest block hash
    pub latest_block_hash: BlockHash,
    /// Forked network info
    pub forked_network: Option<ForkedNetwork>,
    /// Snapshots of the chain
    pub snapshots: BTreeMap<U256, (u64, B256)>,
}

We could either respect it as is too or add extra ZKsync-specific fields on top (latest batch number and fork batch number come to mind).

anvil_nodeInfo

AFAICT anvil_nodeInfo is anvil-specific and looks like this:

pub struct NodeInfo {
    /// The current block number
    pub current_block_number: u64,
    /// The current block timestamp
    pub current_block_timestamp: u64,
    /// The current block hash
    pub current_block_hash: BlockHash,
    /// The enabled hardfork
    pub hard_fork: String,
    /// How transactions are ordered for mining
    pub transaction_order: String,
    /// Info about the node's block environment
    pub environment: NodeEnvironment,
    /// Info about the node's fork configuration
    pub fork_config: NodeForkConfig,
}

pub struct NodeEnvironment {
    /// Base fee of the current block
    pub base_fee: U256,
    /// Chain id of the node.
    pub chain_id: ChainId,
    /// Configured block gas limit
    pub gas_limit: U256,
    /// Configured gas price
    pub gas_price: U256,
}

pub struct NodeForkConfig {
    /// URL of the forked network
    pub fork_url: Option<String>,
    /// Block number of the forked network
    pub fork_block_number: Option<u64>,
    /// Retry backoff for requests
    pub fork_retry_backoff: Option<u128>,
}

Similar situation here wrt our options but the difference here would be bigger due to our fee structure being completely different.

If we decide to keep complete compatibility with both then we will still have an option to add our own endpoint with control over response format.

@dutterbutter @popzxc WDYT?