Movel Bazel workspace root to project root

[smolkaj]

Currently, MODULE.bazel and WORKSPACE.bazel live in proto/, making proto/ the root of the Bazel workspace, due to the following TODO:

proto_library(
    name = "p4types_proto",
    srcs = ["p4/config/v1/p4types.proto"],
    # TODO(github.com/grpc/grpc/issues/20675): strip_import_prefix breaks
    # cc_grpc_library. Make proto folder the Bazel root folder as a workaround.
    # strip_import_prefix = "proto",
)

I think the underlying issue has been fixed and we can now resolve the TODO.

While we're at it, we should also move our BUILD targets so they live in the same folders as their source files to align with Bazel best practices.

NOTE: The proposed changes will break existing users, who will have to update their build files. So im a bit unsure if this cleanup is worth all the churn this will cause downstream.

Impact

Having the Bazel workspace root not be the root of the project is very unusual and causes some extra friction: for example, it's not straightforward to tell that p4runtime is a Bazel project (due to the missing files in the root folder), and users need to set a special strip_prefix argument when depending on p4runtime:

• p4runtime/bazel/example/using-bzlmod/MODULE.bazel

  Line 15 in b607cab

  # strip_prefix = "p4runtime-1.4.1/proto",

• p4runtime/bazel/example/using-workspace/WORKSPACE.bazel

  Line 13 in b607cab

  # strip_prefix = "p4runtime-1.4.1/proto",

[smolkaj]

Actually, how about defining aliases in the root BUILD file? And perhaps in the proto/BUILD file, for those of us (@jonathan-dilorenzo @matthewtlam 😉 😉 ) who integrate the p4runtime folder into a mono repo? That should make this refactoring fully backwards compatible, if I am not mistaken.

We could deprecate the aliases right away and remove them in 2.0.0 ...