Separate out generation of protobuf messages and gRPC services

[daviddrysdale]

We currently generate two different things from our .proto files:

• Rust structs to match protocol buffer message definitions. These are generated by Prost in the standard way.
• Rust structs, traits and methods that correspond to gRPC service definitions. These are produced by an Oak-specific generator, and the generated code is intended for use inside an Oak Node; in particular, it relies on the existence of the Oak SDK.

For protobufs used in communication with the Runtime, the message definitions are effectively part of the Oak ABI, and so belong in the oak_abi crate.

However, the generated service code is not part of the ABI; it belongs in the SDK and can't be part of oak_abi (because it would induce a dependency cycle oak_abi -> oak -> oak_abi).

So these two types of generated code should be separate. A large fraction of this is covered by #1086, which allows the generation of just the message definitions in a .proto file.

However, it would be nice to tidy up and complete the process – for example, after #1086 the message definitions for the Roughtime service are in two places:

• oak_abi: message definitions on their own
• oak: message definitions and gRPC service code.

Ideally the latter would just have the gRPC service code, and would import the message definitions from the former.

[daviddrysdale]

One further thing: we actually generate three different chunks of Rust code from our .proto files:

• structs for messages.
• Oak-specific code for gRPC services, both client- and server-side.
• Also: external/host-system code for gRPC services, just for the client-side, as generated normally by tonic-build.

The last of these is needed for clients of Oak Applications that are written in Rust. That certainly includes the trusted_information_retrieval Rust client, but after #1038 will also include all of the integration tests for example applications.

[daviddrysdale]

I think this is now done (with #1108 and friends)