Fix aliased crate handling in aliases attribute

[ashi009]

Description

This PR fixes an issue where crate_universe configuration using default_alias_rule_bzl would fail when processing aliased crates in the aliases() function.

Problem

When using default_alias_rule_bzl in crate_universe configuration, Bazel fails to build targets that depend on aliased crates. The error occurs because the current logic assumes a direct correspondence between target labels (k.label) and their crate info owners (crate_info.owner), but for aliased targets, crate_info.owner points to the original target, not the alias label.

Solution

This change updates the alias resolution logic in rust/private/rustc.bzl to correctly handle aliased crates by:

1. Checking if a target has rust_common.crate_info
2. Using crate_info.owner if available, otherwise falling back to k.label
3. Ensuring consistent alias generation for both regular and aliased targets

Code Changes

Modified files:

• rust/private/rustc.bzl: Updated alias processing logic in collect_deps function

Before:

aliases = {k.label: v for k, v in aliases.items()}

After:

aliases = {
    k[rust_common.crate_info].owner if rust_common.crate_info in k else k.label: v
    for k, v in aliases.items()
}

Testing

This fix enables the use of default_alias_rule_bzl functionality without breaking alias generation for crates that have aliased targets.

Related Issues

Fixes #3692

Checklist

• Code follows the existing style and patterns
• No breaking changes to existing functionality
• Maintains backward compatibility
• Issue was created and linked

---

Note: This change is essential for users who want to leverage default_alias_rule_bzl with crate_universe to integrate with existing Bazel rule sets like @rules_cc.

[UebelAndre]

Thanks! Could you also add a starlark unit test for this in test/unit/aliases or something?