Decouple stress-test from block-producer

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.