Consider [de]serialization without explicit pbjson-types

Thanks for your work on these crates, they're super useful.

I have a design question that I'm wondering if you all have given any thought: could the serialization/deseralization code-gen be written in such a way to convert the well-known types in prost-types directly, without substituting pbjson-types?

For example, the code gen could detect whether a field has a known type, and then invoke a free-standing [de]serialize function to convert a prost-type, instead of using the trait-based type serialization. This would be similar to the #[serde(with = ...)] attribute that substitutes in functions, applied within the generated trait code

The motivation is to have a single "canonical" source for the well-known types, to make things like From impls simpler for user types. For example, suppose I have an internal timestamp type, with impl From<MyTimestamp> for prost_types::Timestamp. Adding another impl for pbjson::Timestamp is easy enough, but it's more code and exposes the json support in the types rather than only an implementation detail.

I'm wondering if this approach is possible, and if it's something you'd consider. It would be behind some flag on the builder of course, to give users the option to opt-in or to continue with the current type-based approach

Start by reviewing the code-generation builder and how it currently handles well-known types from prost-types and pbjson-types. Assess whether an opt-in path can use standalone serialization and deserialization functions for prost-types while preserving the existing type-based approach. Done means the design is resolved and the requested builder option and generated behavior are specified.