Emit canonical dependency info when assembling crate

[dmitrii-ubskii]

What is the goal of this PR?

We improve the generated crate manifest by allowing to specify available crate features, and by enabling the features of dependencies.

What are the changes implemented in this PR?

We did not include enabled features in the crate dependencies before this change. Now, we parse the crate universe manifests and collect the crate_features attributes from the rust_library dependencies of the crate being assembled so that we can emit the correct dependency requirement in the generated Cargo.toml.

rules_rust must resolve the full list of features which were enabled explicitly or implicitly in order to correctly compile the dependency. That has the consequence of us ultimately explicitly depending on implementation details of other crates (see e.g. https://github.com/vaticle/typedb-driver-rust/issues/35), which is misleading on the crates.io page, and breaks across dependency versions. For this reason, we cannot simply rely on the crate_features attribute of the generated dependency files, but must instead parse the explicitly enabled features in the universe manifests.

[vaticle-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [ ] This change is trivial and does not require a code or architecture review.

Code

• [x] Packages, classes, and methods have a single domain of responsibility.
• [x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [x] The code is canonical and the minimum required to achieve the goal.
• [x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [x] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [x] Any required build and release automations are updated and/or implemented.
• [x] Any new components follows a consistent style with respect to the pre-existing codebase.
• [x] The architecture intuitively reflects the application domain, and is easy to understand.
• [x] The architecture has a well-defined hierarchy of encapsulated components.
• [x] The architecture is extensible and scalable.