feat: support protoc options

[comynli]

Protobuf compiler typically pass arguments using -xxx_out=options:$path or -xxx_opt=options. This PR makes the vertx-grpc-protoc-plugin2 follow this convention

[vietj]

we should be consistent and name like for the Maven plugin "grpc-io" and not "io", etc...

can you sign the Eclipse Contributor Agreement ?

[comynli]

we should be consistent and name like for the Maven plugin "grpc-io" and not "io", etc...
Ok, I'll fix it quickly.

[vietj]

@comynli you need also to sign the eclipse contributor agreement so we can accept your contribution

[comynli]

@comynli you need also to sign the eclipse contributor agreement so we can accept your contribution

Already done. I am very sorry, I am not very familiar with English, and I spent some time understanding it.

[vietj]

can you instead reuse the same command line parser instead of parsing with a different syntax

[zZHorizonZz]

Could we maybe use this type of options in IT test module instead of args to ensure everything works as expected? What do you think @vietj

[vietj]

@zZHorizonZz I am not sure what you mean, can you elaborate ?

[zZHorizonZz]

So I think we need to be able to test this somehow, because hoping that this won't break with potential updates etc. doesn't seem like a good idea. So I think we should at least be able to test it, and because you should be able to pass the plugin parameters through <pluginParameter></pluginParameter>, that should basically trigger this type of argument parsing? Other variant is to have possibly gradle project which is using this, as folder and triggere it during build?

[comynli]

can you instead reuse the same command line parser instead of parsing with a different syntax

Sorry, this has been quite a busy day. Do you mean to use Picocli to parse the parameters passed to the plugin by protoc? Or should it maintain the same behavior as args?

[vietj]

we would like to support a single way to transform a stream of tokens into the plugin configuration using the picocli engine