I recently merged #1140 which introduced a new, highly-customizable swift_proto_library implementation.

However, because this dropped support for the proto aspect, consumers of the deprecated rules who relied on this behavior and don't want to use a tool like gazelle to generate their build files will have a hard time migrating to the new rules.

This PR introduces a new swift_proto_library_group rule which uses an aspect and functions very similarly to the deprecated rule to facilitate their migration. Because of the limitations of aspects, though, they will be unable to benefit from some of the customization options afforded to the new swift_proto_library rule including custom module names. This was true of the deprecated rules and it will be true of the aspect-based rule as well.

To avoid repeated / diverging logic, I extracted most of the logic necessary to generate the swift source files and compile them + aggregate the providers into the swift_proto_utils.bzl file and shared this between the swift_proto_library and swift_proto_library_group rules.

I've also added a working GRPC example which shows how to combine swift_proto_library and swift_proto_library_group targets. As with the old rule, swift_proto_library_group does not support GRPC generation directly. However, you can create a swift_proto_library target to generate your service protos which depends on a swift_proto_library_group which generates everything else. This is how the deprecated rules behaved with a swift_grpc_library depending on a (deprecated) swift_proto_library target.