Support RunfilesGroupInfo

[malt3]

Teach the Java rules to describe their runfiles as named, ordered groups so that downstream packaging rules can build more efficient artifacts.

java_binary, java_test, java_library, and java_import now return RunfilesGroupInfo (and RunfilesGroupMetadataInfo) from the rules_runfiles_group ruleset alongside DefaultInfo. Instead of seeing a single flat runfiles tree, a packaging rule (e.g. a container-image or archive rule) can split a binary's runfiles into layers and order them so that the content that changes least often lands in the most cacheable layers:

• the JDK / java_runtime at the foundation tier (never merged),
• java_import targets (typically third-party jars) at the shared-deps tier,
• first-party java_library code, the binary's own jars, and the executable at the executable tier.

Libraries propagate fine-grained per-target groups up through their dependents; the binary collects them, adds its own groups, and tags every group it produces with the rules_java merge affinity so that JVM-shaped groups stay together when a packager has to merge groups to fit a layer limit. java_import gains a runfiles_weight attribute so dependency-management rulesets can hint at relative sizes to guide those merge decisions.

Consumers that don't understand RunfilesGroupInfo are unaffected and keep using DefaultInfo.default_runfiles.

Adds a dependency on rules_runfiles_group for both Bzlmod and WORKSPACE setups.

Validation

I took the liberty to host a BCR mirror that has support enabled for rules_java and rules_img. I also created a demo repo to show the effect.

This shows two java_binary targets with overlapping dependencies. Both are packaged as container images.
Without RunfilesGroupInfo, the whole java_binary is stored as a single layer and there is no sharing (only the base image layer is shared):

With RunfilesGroupInfo, individual runfiles from java_library targets get their own layers and most of the content is shared across the container images:

[malt3]

I discussed with @fmeum that it's possible to make this provider a lot more memory efficient. I'll also add a global flag to enable/disable the emition of this provider for memory conscious users.
I'll update this PR accordingly.

[fmeum]

You can mark this rfr.

[malt3]

You can mark this rfr.

I will, but it's referencing a prerelease version of rules_runfiles_group.
I'll kick off a new release of that module now. Just FYI for any reviewer.

EDIT: done. Now pointing at rules_runfiles_group@0.1.0