Redesign the Rust crates.

[smolkaj]

This is a revamp of #483, cc @duskmoon314 @chrispsommers @antoninbas.

It makes the following high-level changes:

1. Changed: The generated files are no longer checked in. See below for rationale.
2. Changed: Compile-time code generation is now fully controlled within rust/ following standard Rust/Cargo conventions.
3. Added: CI script to ensure that the Rust crates build.
4. Added: Support for grpc reflection by exporting a FileDescriptorSet.
5. Added: README and code comments for documentation.
6. Changed: The code is now split into 2 crates providing the message types and client/server service code, respectively. This allows users to avoid pulling in unnecessary dependencies and is more future proof, since the libraries prost and tonic are just 2 of several alternative proto/grpc implementations in Rust, and there is also an official Google grpc-rust project in the works. With the new design, we can easily add additional crates for other Rust proto/grpc implementations down the road if needed.
7. Changed: google.rpc.Status is now vendored in the proto/ directory to simplify the build, since there was no Rust crate providing it available. I added a Github Action to ensure the file stays up-to-date (though it hasn't seen any changes in years anyway).
8. Changed: simplified codegen/ based on (2) and (7).
9. Changed: Upgraded all dependencies to their newest versions (cargo upgrade --incompatible).

Breaking changes

This PR does make some breaking changes:

• p4runtime::p4runtime_{server, client} moved to p4runtime_tonic::p4::v1::p4runtime_{server, client} to mirror the proto path p4.v1.P4Runtime of the corresponding service, following standard conventions.
• Due to (9), there are some changes in the generated code.
• The crate p4runtime was replaced by 2 new crates p4runtime-prost and p4runtime-tonic.

@duskmoon314, please let me know if you have any concerns about the breaking changes. If so, it would be easy to add back a legacy crate p4runtime to provide backwards compatibility. Or, you could just point to an older version of this repository in your Cargo.toml:

p4runtime-prost = { git = "https://github.com/p4lang/p4runtime.git", tag = "v1.4.1" }

To check in or not to check in

With this PR, the generated code is no longer checked in. On the one hand, this has some advantages:

1. easier maintenance
2. simpler codegen script
3. code generation fully controlled in a single place (rust/) using a idiomatic Rust/Cargo setup
   • This is what prompted this redesign: Previously, upgrading proto/grpc/prost/tonic versions for Rust had to be coordinated across several places, including codegen/Dockerfile and rust/Cargo.toml.

On the other hand, as @duskmoon314 explained in #483 (comment):

I think checking in the generated code has two pros:

1. People can view the generated code. (Though this may not be very useful.)
2. Rust can use a crate (library, package) directly from GitHub (or other remote repo). Thus, users can test an unreleased main branch easily.

I addressed these points as follows:

1. I provided two ways of viewing the generated code in the rust/README.md (though they are admittedly not as convenient as seeing the code right on GitHub).
2. The new crates can still be consumed directly from GitHub, as explained in the rust/README.md. This seems to have been a misunderstanding of how this mechanism works.