Framework support for gRPC

[jumaffre]

Now that we have support for gRPC at the application level, the framework should also support gRPC to report consistent errors to clients. For example, currently, if a gRPC application defines an authentication policy throws an authorisation error, this error will be formatted by the framework and returned as JSON, which at best will be confusing to the gRPC client.

Instead, we should format the errors based on the content type header of the incoming request. The existing governance and operator endpoints will remain as JSON only.

Tasks:

• 1. Separate gRPC headers from private implementation
• 2. From status.proto, link status.pb.cc to libccf_endpoints
• 3. Format frontend errors as JSON if request content-type: application/json or framed protobuf if request content-type: application/grpc (facilitated by Refactor frontend to remove return-based response, and retry endpoint lookup on conflict #4205): Automatically return gRPC errors for framework-level errors #4813

[jumaffre]

This work will be necessary to support gRPC apps, e.g. https://github.com/microsoft/LSKV.

[eddyashton]

Protobuf v22 includes a hard dependency on Abseil, so we don't want to include that as a dependency for all CCF apps. We think that's fine - the framework can speak HTTP/2 and produce gRPC error trailers, and protobuf parsing/encoding is only necessary in the application. We may still want to build an enclave-friendly, mitigated version of protobuf, and distribute it with CCF for easy app consumption, but we don't want to link it in every app.