Decouple stress-test from block-producer

[Mirko-von-Leipzig]

The stress-test binary added in #657 currently relies on the block-producer's StoreClient implementation.

This is mostly because this client does some DTO wrapping so it was easier to use in place.

There are a few approaches here, but with the gRPC refactoring done in #723 we should be in a good position to create nicer, re-useable abstractions.

There are likely more use cases for having better internal gRPC clients that aren't bound to the specific component's crate, e.g. for use in benchmarking or other tooling that should live separately.

Something to consider in this particular case, is to separate the current store.proto gRPC service definition into two. At the moment it contains an amalgamation of the gRPC API required by the RPC and block-producer components. Instead we could reduce store.proto to the API required by the block-producer (which is quite minimal), and the store component would serve two separate gRPC APIs. In this case it would (currently) also be unnecessary to duplicate the RPC gRPC definitions - the store would simply host the RPC defined server.

The internal proto crate could rather trivially create a StoreClient wrapper for the gRPC API required by the block-producer. It would be rather small and could be done independently of the above.