Support proc macros and fix dependency name detection in `assemble_crate`

[alexjpwalker]

What is the goal of this PR?

assemble_crate now supports procedural macro dependencies, and is more reliable at correctly detecting the crate names of all dependencies. In particular, crates with hyphens (such as async-trait) should no longer cause issues.

What are the changes implemented in this PR?

Previously assemble_crate aggregated dependency info via only the deps attribute of a rust_* target. Now, proc_macro_deps is traversed as well.

Also, crate name detection has been reworked. Because rules_rust doesn't expose the original name of the crate downloaded from Cargo anywhere, we were unable to reliably get that crate name and put it into Cargo.toml. Now, we use string parsing against the target's label. This works because the label is (e.g):

@crates__async-trait-0.36.0//:async_trait

We take everything up to + excluding the first ., then take everything up to + excluding the last -, then strip @crates__ from the front.

It looks like a dumb hack (and it is), but it works. I've raised:

• https://github.com/bazelbuild/rules_rust/issues/1783

[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

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

Code

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

Architecture

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