Feature request: field_behavior support

[Tudyx]

We are using tonic in a service handling user commands. These commands are used later in our business logic and have required Message field which is generated by prost as Optional as stated in the proto3 specs.

Google has a workaround for having required fields while still respecting the proto3 specs, they are using field_behavior.

The syntax looks like this.

message Foo { 
  Bar bar = 1 [(google.api.field_behavior) = REQUIRED];
}

message Bar { 
  string s = 1;
}

They are using it a lot, for instance in pubsub proto.

The idea is not to make the field optional if its "tagged" with [(google.api.field_behavior) = REQUIRED];.

Related to #521

[jwilm]

Chiming in from OneSignal - we have found that across engineering we burn a non-trivial amount of time writing conversions simply to get all of the Option handling out of our business code. It's been extensively discussed elsewhere on the issue tracker how tedious and time consuming this can be, so I'll just leave it at that.

We would love to see a mechanism for the code gen to obviate the need for this Option-eliminating boilerplate that comes with every new RPC endpoint. The field_behavior attributes are generally a great solution to this.