Support external repository labels in package_group

[meteorcloudy]

Description

This PR enables package_group to correctly interpret labels that include external repositories (e.g., @module//... or @module//:__subpackages__).

Motivation

Previously, PackageSpecification.java strictly required package names to start with //, failing on labels with repository prefixes. This made it impossible to define a package_group that includes packages from other Bzlmod modules. This change leverages Label.parseWithRepoContext to correctly resolve repository mapping and validate package specifications within the context of the repository where the package_group is defined.

Fixes an issue where bazel build would fail when a package_group referenced an external repository in its packages attribute.

Build API Changes

Yes. This change affects the behavior of the package_group rule and the visibility() function in .bzl files.

1. Has this been discussed in a design doc or issue? No, but the change and impact should be straightforward to understand.
2. Is the change backward compatible? Yes, it relaxes a restriction that previously caused errors.
3. If it's a breaking change, what is the migration plan? N/A

Checklist

• I have added tests for the new use cases (if any).
• I have updated the documentation (if applicable).

Release Notes

RELNOTES: package_group now supports labels with external repositories in the packages attribute.

[meteorcloudy]

@brandjon @Wyverald What do you think about this change?

@mkruskal-google needs this for limiting certain abseil targets visibility to a specific new BCR module.

     visibility = [ "@foo//bar:__subpackages__"],

already works when you have a bazel_dep on foo (assuming this dependency won't cause much problem), this change allows such declaration also in package_group.

[fmeum]

Does this work with nodep deps? That would resolve concerns about increased dep footprint.

[meteorcloudy]

@fmeum Unfortunately no, nodep requires repo_name = None, so the label will be invalid. @mkruskal-google is aware of the dep footprint problem, but it should be fine for this specific case (just a standard C++ library).

[meteorcloudy]

FYI @gregestren