Consideration: Deprecate gRPC integration

[xerial]

Deprecate gRPC integration. Airframe gRPC integration was introduced to facilitate efficient server-client communication. However, I'm considering dropping gRPC support for the following reasons:

• gRPC single/async performance is now on par with the airframe-netty backend. There's no significant difference in performance, with both handling about 10,000 to 60,000 RPC calls per second.
• grpc-web hasn't been updated recently, making it less appealing as a web-server backend for Scala.js client communication. Next release grpc/grpc-web#1466
• The expected use cases for server/client/bi-directional streaming (e.g., chat, video streaming, online gaming) aren't always our primary focus. https://yousufsohail.medium.com/bidirectional-streaming-in-grpc-dcf8ae814a2f
  Moreover, most gRPC ecosystems assume the use of ProtocolBuffers, making streaming JSON/MsgPack data over gRPC less practical for our needs.

While the maintenance overhead for airframe-grpc has been relatively low due to its isolated nature, there are still some factors to consider before making a final decision on deprecation:

• Current use case: The use case of airframe-gprc is small, even for myself, so it's not a big concern.
• Future potential: Consider if there are any upcoming use cases or projects that might benefit from airframe-grpc. Sometimes, seemingly less-used modules can become valuable in future scenarios.
  • grpc-java represents an advanced use case of Netty, so having airframe-grpc still has a value as a comparison target when we need to support more streaming use cases over airframe-http-netty.
  • How difficult to support protobuf? Possible to use protocol buffers with airframe RPC? #3335 ScalaPB generates Scala case classes and interface from .proto files. Can't we generate Airframe RPC (Scala) interface and model classes from .proto?