architecture: infra should not depend on interfaces

[battlmonstr]

infra is a collection of generic low level components.
interfaces contains code generated from .proto files for each of the GRPC services we implement

currently infra depends on interfaces for the following reasons:

1. client_context_pool_test and call_test depend on kv.proto as a service example to do the calls against
2. mock fix 24351: extra mocks added on top of existing generated mocks to fix an bug
3. version.hpp: defines versions of each service and helpers to call rpc Version method (it exists on all services)
4. conversion.hpp: defines convertions between numeric types from types.proto (e.g. ::types::H256 and intx::uint256, types::H160 and evmc::address etc.)

Logically each generated interface is a requirement only for each particular service client/server implementation. interfaces should be decoupled from infra, otherwise since everything depends on infra everything ingests low level details about all existing services.

Short term:

1. move tests to a higher level module, e.g. a module that implements KV server/client.
2. generate mock fix 24351 mocks within interfaces (or update grpc to fix 24351)
3. version.hpp: the methods are only used in daemon.cpp Daemon::run_checklist(), so wait_for_xxx_protocol_check helper methods could be moved to rpc. The actual version number constants should be moved to the implementation of each service. ProtocolVersion struct can and wait_for_protocol_check template be kept in infra.
4. conversion.hpp: move to a separate library that depends on types.proto (types.pb.h) and implements conversions. This could be a sub-library of infra.

Long term:
Instead of all services being generated in one place (interfaces). We could refactor cmake code gen functions to be able to work with any service .proto with details about a particular service provided as inputs. Using these functions the actual code gen can be used in other modules. Each implementation module defines targets like silkworm_interfaces_xxx for internal use. For example, sentry defines silkworm_interfaces_sentry, which is then used for sentry client/server impls.