Split googleapis into per-language modules

[fmeum]

Introduces new googleapis-* modules that contain the per-language module dependencies needed to support the individual rules used by the main googleapis module. This allows BCR modules to declare dependencies on language-specific rules in googleapis without requiring that module to depend on every possible language ruleset, which isn't sustainable.

This results in a breaking change for root modules that previously used the switched_rules extensions. These modules now need to explicitly declare deps on the googleapis-* flavors they need, but will be guided through the process by error messages.

In the future, new flavors can be added in a backwards compatible way.

googleapis-grpc-cc is blocked on #3470, which adds a release of grpc including grpc/grpc@3f001f7.

[bazel-io]

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (googleapis-cc, googleapis-go, googleapis-java, googleapis-python, googleapis) have been updated in this PR. Please review the changes.

[bazel-io]

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (googleapis-cc, googleapis-go, googleapis-grpc-cc, googleapis-grpc-java, googleapis-java, googleapis-python, googleapis) have been updated in this PR. Please review the changes.

[bazel-io]

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (googleapis-cc, googleapis-go, googleapis-grpc-java, googleapis-java, googleapis-python, googleapis) have been updated in this PR. Please review the changes.

[fmeum]

TODO: Replace with a better source after #3474.

[mering]

Couldn't we just allow url to be not set when overlay is used?

[fmeum]

We could, but that would require raising the minimum Bazel version to at least 8.1.0 (the earliest we can ship this).

[mering]

Another thing which just came to my mind: Uploading new versions will become much more work with this approach. This is especially relevant since we don't have active maintainers for this package and are even further away from release automation. So it will become less likely that people contribute version updates.

[fmeum]

We should avoid making updates more complicated, but I don't see why this would make it so. Instead of the patches, there are now a few overlay files, but that's the only change I see. The "flavor" modules only need new versions if the targets generated in googleapis change in a fundamental way. Do you see other downsides to this approach?

I'm thinking of adding a tool to the repo that creates a new version of an existing module by symlinking over files that haven't changed and replacing the old version with the new version in module files, URLs and prefixes. That should make it very easy to update googleapis, regardless of which approach is used. What do you think about that?