feat!: Support JSON conversion for scalar wrappers

[dcodeIO]

Adds JSON conversion support for google.protobuf.*Value scalar wrapper types in converters:

• google.protobuf.DoubleValue
• google.protobuf.FloatValue
• google.protobuf.Int64Value
• google.protobuf.UInt64Value
• google.protobuf.Int32Value
• google.protobuf.UInt32Value
• google.protobuf.BoolValue
• google.protobuf.StringValue
• google.protobuf.BytesValue

Example:

message SomeMessage {
  google.protobuf.StringValue name = 1;
  google.protobuf.Int64Value count = 2;
  google.protobuf.BoolValue flag = 3;
  google.protobuf.BytesValue data = 4;
}

const message = SomeMessage.fromObject({
  name: "abc",
  count: "123",
  flag: false,
  data: "AQI="
});

SomeMessage.toObject(message, {
  json: true,
  longs: String,
  bytes: String
});
// { name: "abc", count: "123", flag: false, data: "AQI=" }

Unlike the existing google.protobuf.Any wrapper in wrappers.js, these value wrappers are simple enough to implement at the shared codegen level, so they also apply to generated static code.

Related: #677, #1312, #1304

[alexander-fenster]

This is great; I'm a little bit concerned that it's a breaking change for those who depend on the existing format. If we are considering major version bump soon, maybe feat!: just to be safe?

[dcodeIO]

True, this is essentially two pieces:

1. It adds support for scalar inputs where we previously only supported { value: ... }. This is a regular feature, because previously unsupported inputs are now supported.
2. It changes outputs from { value: ... } to plain scalar values when using { json: true } or .toJSON(). From a conformance perspective, this is a fix, because the previous behavior was non-standard. From a compatibility perspective, this is a breaking change, because some consumers might already depend on the non-standard behavior.

So yes, as-is, marking this as feat!: is the safer choice. Alternatively, the PR could be split into its feature and breaking components, leaving the output change for a later major release. Thoughts?

[dcodeIO]

One good argument against splitting is that there's more WKT work perspectively, so locking the mechanism in 8.x already is risky. Likely best to keep the mechanism itself for 9.x then.

[alexander-fenster]

Let's just do a single feat!. If you are planning more patch / minor releases, this one can probably wait until the good time to go to 9.x.

I'm surely aware of at least one package that would be affected by the breaking change, it's proto3-json-serializer that I wrote a few years ago for Google. It still depends on v7, but upgrading it to v9 will require someone to go make some (trivial) changes in this code that depends on the internal representation.

Shall we probably make a branch for collecting 9.x features?