Consider making client crate depend on a new store crate

On #1253, we moved store implementations into their own crates. This implied moving tests to a new crate as well, since most of the tests were based on `SqliteStore` and we want to avoid dependency loops. We could explore refactoring the crate dependency chain in a way where the client depends on the `Store` trait which could live on a separate crate.

> I wonder if the crate dependency path is the right one here. Conceptually, the client depends on the store, not the other way around. Aside from a few of the imports from `miden_client` that could probably be done away with, the main blocker for this obviously be the `Store` trait. If this became its own crate rather than a module within `miden_client` (say, `miden-store-traits`? A little similar to [`RustCrypto/traits`](https://github.com/RustCrypto/traits)), then we could remove this unnatural dependency path (it goes in the direction of ports-adapters pattern)
> ### Currently
>`sqlite_store` -> `client`
>
>### Proposed
>`sqlite_store` -> `store`
>`client` -> `store`
>
>All that said, my context and experience of working with the stores is definitely more limited, so I'm not sure whether this fits to our use case.

_Originally posted by @mmagician in https://github.com/0xMiden/miden-client/issues/1253#issuecomment-3281056983_

I believe the current setup makes sense but this idea might be worth discussing and implementing, so opening an issue to track this. If we wanted to work around the dependency loop issue, we could also move tests back to the `miden-client` crate, and implement an in-memory store or something simple enough that would work for these scenarios.