Handle well-known wrapper types in a way that matches grpc-gateway serialization/deserialization

[seanami]

Given that the stated goal of this project is to generate idiomatic Typescript code for the grpc-gateway project, I thought this might be a useful contribution, but it seems like it's also a bit of a departure from existing behavior, so there might be some discussion.

Further work that I know is needed:

• A better way to check for or define these constant values we're checking for.
• Adding tests (I'm not able to get the tests to run).

---

The default JSON marshaller/unmarshaller for the grpc-gateway has the following behavior for well-known wrapper types like BoolValue and StringValue:

• Serializes those types as boolean or string types, or undefined if nil
• Expects incoming values for those types to be boolean | undefined, or string | undefined, and knows the difference between an empty param (empty value) and a missing param (nil value)

However, the default behavior of this library has a couple differences of behavior that make working with these wrapper types difficult/inconsistent/partially-broken:

1. Well-known wrapper types are serialized by importing an external file with that message definition, resulting in { value: boolean } or { value: string } as types
2. Well-known wrapper types can't be output to URL params by the helpers used in service client definitions, because zero-value query params are always omitted

This branch contains fixes for those two issues:

1. Well-known wrapper types are serialized as their Typescript-native equivalents, matching how grpc-gateway serializes them and expects them to be sent back.
2. URL param serialization is changed to allow serializing zero-values for primitive types (string, number, and boolean), which makes these well-known wrapper types work in GET request messages.

[dpup]

I'd like to see this change landed too. Are there any active maintainers on this project anymore?