Split up the protoc plugin to make gRPC content configurable

[nat-n]

Currently there is a single plugin with limited support for generating gRPC client code, and there is demand to cover servicer generation #19, with grpclib or grpcio, or none #44 #20 .

Since AFAIK there is not standard way to provide arguments to protoc plugins, I propose that the plugin be exposed as multiple distinct executables, one to generate just the protobuf dataclasses, one to generate the dataclasses and grpclib client/server and one to generate dataclasses and grpcio client/server.

Are there other approaches worth considering?

[roblabla]

Since AFAIK there is not standard way to provide arguments to protoc plugins, I propose that the plugin be exposed as multiple distinct executables

this is wrong. We can pass arguments to protoc just fine, e.g. protoc --python_betterproto_out=out --python_betterproto_opt=enable-grpc will put enable-grpc in the CodeGeneratorRequest's parameter field. It is usually a coma-delimited list of elements.

[Gobot1234]

Yeah this is an old issue, we actually use custom options https://github.com/danielgtaylor/python-betterproto/blob/master/src/betterproto/plugin/parser.py#L75