Motivating examples for adding this type:
* Packaging rules that bundle targets into substructures (e.g. subdirectories).
* Providing hints to aspects via a well-known implicit attribute mapping the names of other attributes to a list of well-known targets representing the semantic meaning of an edge (e.g. "compile time dep", "runtime dep", "third party dep", ...) for use in SBOM generation and packaging.
* rules_js and other rulesets have `patches` parameters on their module extensions that accept lists of patches to apply per external dependency. With WORKSPACE, they relied on `attr.string_list_dict`, but the lack of repo mapping means that there is no direct port. Users would need to migrate to individual tags per hub repo and dep to supply patches.

Adding this type doesn't incur a significant maintenance cost:
* The native attribute type `LABEL_LIST_DICT` already exists (added for `exec_group_compatible_with`), so this only requires wiring it up in Starlark. In fact, some of the added logic (duplicate checking) is relevant for this existing use case, we just forgot to add it.
* A Starlark type with equivalent BUILD syntax already exists (`attr.string_list_dict`), so there is no need for tooling to explicitly support the new type.

Fixes bazelbuild#7989

RELNOTES[NEW]: The new `attr.label_list_dict` type accepts a dict in which keys are strings and values are lists of labels.

Closes bazelbuild#27119.

PiperOrigin-RevId: 828510272
Change-Id: Ibf5ba97d049e592af2f61d91dbaa42cfe264f0bb