Better organize Bazel build definitions so that rules_go isn't a hard dependency

Currently, proto targets for different languages are defined in a BUILD file by loading the [xds_proto_package](https://github.com/cncf/xds/blob/1e77728a1eaa11d6c931ec2ccd6e95f516a7ef94/bazel/api_build_system.bzl#L130) macro (eg. in `//xds/data/orca/v3`). The bzl file that defines `xds_proto_package` again loads macros from rules_go:
https://github.com/cncf/xds/blob/1e77728a1eaa11d6c931ec2ccd6e95f516a7ef94/bazel/api_build_system.bzl#L4

This is a bad practice because it forces any other project (see [grpc](https://github.com/grpc/grpc/blob/89f7534e43cf73f56c492a9cf7eb85ca6bfbd87a/BUILD#L7098)) which depends on any target in `//xds/data/orca/v3` to fetch rules_go, even though the project doesn't depend on the `go_proto_library` target. This is a common pitfall with Bazel, see https://github.com/bazelbuild/bazel/issues/12835

A better package structure is to split targets into different packages by language, eg

- proto_library under //xds/data/orca/v3
- go_proto_library under //xds/data/orca/v3/go
- py_proto_library under //xds/data/orca/v3/py
- cc_proto_library under //xds/data/orca/v3/cc

so that dependencies for specific languages are not fetched when the corresponding package is not needed.

To maintain backwards compatibility, you can still have `alias` targets in `//xds/data/orca/v3`that points to other language specific packages.