FEATURE: Include a gRPC service project as alternative to REST API project

[CesarD]

Detailed Description

Include a new project for implementing a gRPC service as interface for consuming Monaco's demo business as an alternative to the current REST API service project. This new project should be enabled by its own template flag just like the REST API and Worker Service ones.
Also, the YARP API Gateway implementation should leverage this to include the corresponding mappings to route from the external REST endpoints to the new gRPC service.
It is expected that the implementation of this gRPC service should be useful for microservices behind an API Gateway/Reverse Proxy and not to be directly exposed to the internet providing authentication in the same manner the REST API project is capable of.

Context

REST APIs are useful for communicating from browsers or for integrating with other external services, but when implementing several microservices interacting with each other or receiving requests from an API Gateway or Reverse Proxy (like YARP in Monaco's case), REST API generates an extra overhead that may increase latency and network traffic: transferring JSON, parsing it, etc.
Since gRPC uses a binary format that is much more reduced than JSON, it helps reduce the traffic and latency only by not having to transfer larger amounts of data in each request as well as the need of parsing human readable text, improving a lot the scenario. But there's also several more features provided by the protocol that will improve the overall communication.

Possible Implementation

The new gRPC service should be enabled by a flag --gRPC that, in a first version, should not include authentication. This flag should also enable the mappings in the API Gateway (if enabled and rendered) so the external endpoints can be redirected directly to the gRPC service accordingly.