refactor: library api reorganization

[mFragaBA]

closes #362. closes #284.

I tried to have each commit as self contained as possible:

• b84c845 refactors the re-exports for the library crate to have a more flattened structure (the code structure stays as is, only exports change)
• 9251fb1 makes StoreConfig an associated type of Store. This allows the consumers of the library to re-use the ClientConfig struct when providing their own store implementation. Not only that but we expect it to satisfy a few trait bounds (usually they can be derived) such as Debug, Default, Eq, PartialEq, Serialize, DeserializeOwned.
• 9587e23 and dde95bb adds features to enable the sqlite store and the tonic rpc client respectively
• 5eebbc5 is pretty self descriptive. The reasoning is that concurrent implies std in base so we should add it here as well to be explicit about it.
• 503a1c9 we remove the feature flags uuid and test_utils. This comes at a bit of a cost. Unless we're on unit tests of the client, we can't use anything under #[cfg(test)] because in those cases (like the CLI and integration tests) the client gets compiled but not in test mode. I couldn't find a built in way to do so and the workaround is what we had with test_utils which is to define a custom feature flag, but the problem is that it cannot be hidden. In order to remove uuid and test_utils I also had to remove some tests from src/cli/..., but considering we're adding very similar tests on #353 it's not a big deal.
• In f87000b we wanted to stop exporting CliConfig from miden_client. The way to do so was by inverting the dependency between it and the ClientConfig struct. So we go from "A ClientConfig can have a CliConfig defined" to "All CliConfig has a ClientConfig defined"
• Lastly, in ff56c79 was something mentioned in comments where we could stop exporting rusqlite and rusqlite_migration as features by prepending them with a dep: on Cargo.toml

Discussion

• I'm thinking that in order to split dependencies that are CLI only we'll probably need to change this into a workspace and have a separate crate for the CLI. That way we can, for example only require figment for the CLI. I think that's a second refactor we could leave for a separate PR, but we can tackle it here.

[tomyrd]

The changes in miden_tx broke some of the imports here, I already commited some fixes to the parent branch so we only have to merge them.

[mFragaBA]

The changes in miden_tx broke some of the imports here, I already commited some fixes to the parent branch so we only have to merge them.

done! Rebased and pushed

[mFragaBA]

• InvalidNoteInputsError seems like an internal-only error which doesn't appear in the public interface. If so, we should hide it (e.g., use pub(crate)).

While it does not appear in the public interface directly, it is used in NoteScreenerError which is part of the public api. Making InvalidNoteInputsError results in the following warning:

 1  warning: type `InvalidNoteInputsError` is more private than the item `NoteScreenerE
 rror::InvalidNoteInputsError::0`
    --> src/errors.rs:398:28
     |
 398 |     InvalidNoteInputsError(InvalidNoteInputsError),
     |                            ^^^^^^^^^^^^^^^^^^^^^^ field `NoteScreenerError::Inva
 lidNoteInputsError::0` is reachable at visibility `pub`
     |
 note: but type `InvalidNoteInputsError` is only usable at visibility `pub(crate)`
    --> src/errors.rs:428:1
     |
 428 | pub(crate) enum InvalidNoteInputsError {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     = note: `#[warn(private_interfaces)]` on by default

[bobbinth]

While it does not appear in the public interface directly, it is used in NoteScreenerError which is part of the public api. Making InvalidNoteInputsError results in the following warning:

Ah - I see! Let's keep it as is then.

[bobbinth]

Is this ready for another review? Or should I hold off for now?

[mFragaBA]

Is this ready for another review? Or should I hold off for now?

should be, yes. I haven't been able to update the PR description to include the newer commits, but looking at the specific commit changes should be pretty self explanatory. Also opened #374 to refactor the errors