[WIP] Avoid intermediate values when serializing and deserializing proto3 JSON

[osa1]

This uses jsontool library to avoid allocating intermediate values when
generating and parsing proto3 JSON strings.

AOT results

	Before	After	Diff
FromProto3JsonString	29639 μs	23353 μs	-6286 μs, -21.21%
ToProto3JsonString	35682 μs	26806 μs	-8876 μs, -24.88%
FromProto3JsonObject	6637 μs	10486 μs	+3849 μs, +57.99%
ToProto3JsonObject	10822 μs	10774 μs	-48 μs, -0.44%

JS results

	Before	After	Diff
FromProto3JsonString	34237 μs	63187 μs	+28950 μs, +84.56%
ToProto3JsonString	71750 μs	47000 μs	-24750 μs, -34.49%
FromProto3JsonObject	17530 μs	35245 μs	+17715 μs, +101.06%
ToProto3JsonObject	20343 μs	19627 μs	-716 μs, -3.52%

Fixes #662

---

cc @rakudrama @lrhn

[sigurdm]

Consider passing an "indent" value

[sigurdm]

Should this really be called writeToProto3Json to maintain consistency?

[osa1]

Additions in this PR will be inconsistent unless we want to do breaking changes.

Currently in master branch (and also in the latest release) we have these generators:

• writeToBuffer
• writeToCodedBufferWriter
• writeToJson
• writeToJsonMap
• toProto3Json

So the proto3 method is already inconsistent.

Without changing it, we can name the new methods toProto3..., or writeToProto3.... Either way it will be inconsistent.

Should we rename toProto3Json? @sigurdm

[sigurdm]

Argh - I see - I introduced that inconsistency - not sure what is the better path forwards.
I guess if we want to be consistent we do:

@Deprecated('Use `writeToProto3JsonMap`');
toProto3Json() => writeToProto3JsonMap();

writeToProto3JsonMap();
writeToProto3Json();

If we prefer to avoid churn over consistency we keep it as toProto3JsonString()....

I guess it's up to your judgement.

[osa1]

Looking at the benchmark results again, we have 3 regressions:

1. AOT JSON object to message
2. JS JSON object to message
3. JS JSON string to message

If we keep the current JSON object parser in mergeFromProto3Json and only use jsontool when parsing JSON strings that will fix (3) as well as we can do mergeFromProto3Json(decodeJson(...)) when targeting JS.

This means extra ~300 lines of code to maintain, per JS format..

When testing, we can avoid duplicating test code by running the tests on JS as well. Since tests are ordinary Dart programs we can compile them to JS with dart compile js ... and run with v8/d8. To keep it easier to compile and run, we could run all tests in a file all_tests.dart (which we used to do a while ago, I think because of how dart test worked at the time) and just compile and run that in CI, instead of each test file individually.

[osa1]

I'm splitting this into two PRs, for generating JSON and parsing JSON. #683 updates JSON generators.