crate_universe: spurious hub alias for an rlib workspace member that has a build.rs

[ashi009]

Summary

crate_universe generates a spurious alias in the crate hub BUILD.bazel for a
first-party Cargo workspace member when that member (a) produces a library
(rlib/lib) target and (b) has a build.rs — even though nothing in the
workspace depends on it. The member is also splice-vendored as
@crate_index__<member>-<version> instead of being left first-party.

Minimal reproduction

https://github.com/ashi009/rules_rust-buildscript-member-alias-repro

A workspace with a single member leaf (crate-type = ["rlib"], an empty
build.rs, depended on by nothing):

$ bazel query '@crates//:leaf'
@crates//:leaf

The generated hub BUILD.bazel contains, under a # Workspace Member Dependencies banner:

transition_alias_opt(
    name = "leaf",
    actual = "@crate_index__leaf-0.1.0//:leaf",
    tags = ["manual"],
)

Delete leaf/build.rs (or drop the library target, e.g. crate-type = ["cdylib"]) and regenerate: the alias disappears and @crates//:leaf no longer
resolves. Both conditions (library target + build script) are required.

Expected

A first-party workspace member that nothing depends on should not get a
@crates//:<member> hub alias (nor be vendored as @crate_index__<member>).

Root cause

1. crate_universe/src/context.rs — workspace_member_deps() collects each
   member's deps including build-script deps. A library crate with a build.rs
   carries a self-edge to its own build_script_build target, so the member
   lands in the set as CrateDependency { id: <self>, target: "build_script_build" }
   — purely because it has a build script. (Confirmed by instrumenting
   render_module_build_file and dumping the dep.)
2. crate_universe/src/rendering.rs — render_module_build_file iterates
   workspace_member_deps() and emits the hub alias gated on
   if let Some(library_target_name) = &krate.library_target_name { ... }, i.e.
   only for crates that have a library target.

So a member's own build_script_build self-edge is being treated as a
"workspace member dependency", and the library gate then turns it into a hub
alias. The fix is to not count a member's self-referential build-script edge as a
dependency for hub aliasing.

Versions

rules_rust 0.70.0, cargo-bazel 0.18.0. The relevant rendering/context code is
unchanged on main at time of writing.