Allow modularized rust targets

[dmitrii-ubskii]

What we have

Currently, a rust_library / rust_binary target is structured essentially like a cargo project without a Cargo.toml.

What we want

If each module of the library is in its own designated bazel package, we can leverage Bazel to enforce the structure. In particular, Bazel bans cyclic dependencies, which will force one-directional coupling between the domain-level modules.

The assemble_crate rule will then generate a single root lib.rs, in which the top-level rust_librarys will be represented as modules, such that we can package and deploy the entire library as a single crate.

Potential pitfalls

• Inconsistent imports between the "dev" and "deploy" versions of the crate: is it typedb_client::common, typedb_client_common, or crate::common? All can be valid at different points, and none is valid at all points.

[flyingsilverfin]

After we allow this, besides moduralising our Rust projects, we should also modularise our Rust project tests, which currently generally all reside within one test target in order to re-use the common functionalities. Instead, we should have Rust test libraries that are used by different test targets.